[This thread seems to have died a week ago, but since I was away, and have
things to say <wink>, and it doesn't seem to be resolved, I figured I'd
resurrect it. While I'm doing notes: thanks Richie, Anthony and Skip for
outlining the various processes in more detail - great stuff for us cvs
newbies].
[Richie]
> Re-reading Tony's mail, I should have pointed out at the time that we
> shouldn't commit edits to both places, but should use "cvs up [-j
> moving-tag] -j release_1_0" to periodically merge the bugfix
> branch onto the head. Nuts.
I've been very guilty of this. Basically for every edit if I thought it fit
in the 'bug fix' category, then I recommitted it on the branch. The
changelog outlines (for the most part) which ones I put into the branch, and
which ones were only on the head.
> From looking at the logs, it seems you're right, Mark -
> bugfixes have been
> hitting the head instead of release_1_0. Also, some fixes have been
> committed to both the head and release_1_0, which will probably make
> merging release_1_0 back onto the head a pain - you always get more
> conflicts when you do that.
Apart from the last couple of weeks, I committed the majority of changes to
the branch (a mixture of stuff from me, and copying other people's fixes
from the head). With the exception of the windows specific stuff, I'm
pretty sure that I branch-committed all the changes that looked to me like
bug fixes. I did do it by copying and pasting, mostly (and then checking),
so hopefully there won't be too many conflicts.
> (I should have encouraged more discussion of
> branch strategy when all this came up - we make heavy use of
> CVS branches at work, and we know a bit about how best to manage them.)
I should asked more questions, too, sorry. I'm very much a newcomer to cvs,
and was probably pushing towards the 1.0 release most for a period, so
should have ensured that I was doing it right.
> How much enhancement work has gone onto the head since release_1_0 was
> taken?
A lot with the web interface. The changelog details it - it's the stuff in
the 1.1a1 section, rather than the 1.0a7 one.
[Anthony]
> I'd suggest the following:
>
> - checkin to the trunk. If the fix is a bugfix, and suitable for the
> branch, include "bugfix candidate" in the checkin message.
>
> - (preferably) check your bugfix into the branch as well. I suggest
> having two checkouts, one on the branch, one on the trunk.
>
> - (otherwise) someone else notices that the "bugfix" needs to be
> applied to the branch as well, and does so.
This is more-or-less what I was doing, I think, except that I based the
"bugfix candidate" decision on discussion in the lists the checkin message,
and my own fallible head, rather than an explicit message.
> Having said that, I'd say the time to branch is at the point
> where we're about to cut the first beta. So we've possibly done
> it too soon here.
This was almost the intent here, too. The original aim was to create the
branch, release 1.0a6, then in a very short time release 1.0b1; before
release the code that became 1.0a6 seemed pretty stable, and the main reason
for the release was to have an alpha with the new script/option names before
releasing a beta. Of course, after it was released, the
db-closing/interface bug surfaced, and there was a resurgence of
dbrunrecovery errors, plus a few others.
[Richie]
> Our failure this time, if there even was a failure, was in
> not advertising the strategy loudly enough.
When a strategy is decided, what would be the best way to advertise it,
given that people may join the development team at any point? Something in
readme-devel?
And speaking of deciding a strategy, what is the spambayes one? <wink>.
Personally, I'm in favour of someone else deciding and giving me steps to
follow :) It does seem likely that if we can resolve the db corruption bug,
a beta wouldn't be far off, so it would be good to decide by then :)
=Tony Meyer
