I want to get the key generator changes in for M4. However, I'm
currently blocked because I can't add the new module to TranQL. So I'd
like to resolve that before the branch. Other than that, I'm fine to go
ahead with the 24 hour notice.
Oh, I think we also have a problem where the currently running
module list never gets saved. So you always get the default services when
you start the server. I think I remember a conversation about how it
was caused by some bad logic around our shutdown hooks. That needs to be
resolved too.
Aaron
On Mon, 4 Jul 2005, David Blevins wrote:
> Do we have a consensus that we should branch at the beginning of the release
> cycle instead of at the end as we have done in the past?
>
> If so, going to put out an email titled "M4 - 24 hour notice of branch",
> which I think would be a good release practice.
>
> -David
>
> On Mon, Jul 04, 2005 at 07:15:34PM -0700, David Blevins wrote:
> > On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote:
> > > David Blevins wrote:
> > > >On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote:
> > > >
> > > >>David Blevins wrote:
> > > >>
> > > >>>Anything I missed?
> > > >>>
> > > >>
> > > >>SNAPSHOT elimination so the build is reproducible.
> > > >
> > > >
> > > >Right. Missed that one for M3 IIRC.
> > > >
> > > >
> > > >>Branch so that M4 can stabilize whilst other changes are being made.
> > > >
> > > >
> > > >We do for every milestone. Don't expect this to be different.
> > > >
> > > >
> > > >>Acceptance test process - how do we know what works (need to avoid a
> > > >>broken release like M3).
> > > >
> > > >
> > > >That's what I meant by:
> > > >
> > > > DB> We have a number of people interested in testing. I'll ping
> > > > DB> them when I have something ready.
> > > >
> > > >Was thinking to branch when I dish out the binaries for testing.
> > > >Rather than the "surprise, here is a binary" approach we've done in
> > > >the past. Sounds pretty much like what you are proposing as well.
> > > >
> > >
> > > Yes - in the past we've just tagged and moved on. This time I think we
> > > should create the branch at the start of the process rather than at the
> > > end as there seem to be a lot of pent up changes planned. Yes, we may
> > > need to merge some critical changes back to this branch but hopefully
> > > this can be kept to a minimum.
> > >
> > > So basically,
> > > * create a branch now, say 1.0-M4-prep
> > > * do the stuff we talking about now on that branch
> > > * cut the final M4 distro
> > > * drop the 1.0-M4-prep branch
> > >
> > > Other work can continue on the trunk without destablizing the M4 release.
> > >
> >
> > +1 That's pretty much what I had in mind.
> >
> >
> > -David
>
