MOL release candidate available

[Samuel Rydh]

On Fri, Jan 09, 2004 at 11:37:29AM -0400, Gavin Hemphill wrote:
> ...and I find it much easier to back up 
> to my previous stable position using rpm rather than trying to track 
> down all the pieces by hand.
> 	There appear to be a couple of things that make this more difficult 
> than it should be when using BK.  The first thing is that you only tag 
> the actual releases (and I think the actual 0.9.66 is at least one 
> changeset later than the tag would indicate but I'm probably wrong 
> there).

The 0.9.66 tag seems to be correctly placed.

> Bk revtool lets me look at the changesets but the comments 
> don't usually contain any indication of things like if it's a release 
> candidate.  I guess the real plea here is for more tags since the actual 
> version number of MOL doesn't increase incrementally (and I can see why 
> that would be a pain given the complexity of the build structure.

You probably mean the changeset number :-). But you are correct, the
changeset number can't be relied upon; a specific changeset
could very well have different numbers in different repositories.

I'll probably reorganize things shortly. For one thing, I
want to have a "stable" and an "unstable" MOL tree. I guess I could
also add release candidate tagging. I think the most import thing
is more frequent releases though.

> The other problem I usually have is that the rpmbuild process tends 
> to be the last thing fixed which makes it more timeconsuming to test things 
> as they move along. 

One good way to test mol is running it directly from the
source true Just build mol and do

	cd src ; ./startmol

(you have to be root). This is how I usually invoke mol.

I'm going to repleace the build system entirely and this should
make it easier to maintain the RPM build target. The
autoconf based build system forces you to hop through
loops...

/Samuel