Re: Branching off 2.2

>
> We should get a consesus amongst the candidates to maintain 2.2 branch
> (hub,mg,uwog others...) to actually maintain the 2.2 branch. ie Be
> prepared to backport fixes to 2.2, do periodic releases and keep it
> generally happy.
>
> Also we should work out a consesus for applying bug fixes.
>
> Some options we have would be:
>
> 1. Fix bugs in HEAD and ask 2.2 maintainers to backport.
> 2. Fix bugs in STABLE and ask a new volenteer to forward port.
> 3. Fix bugs in BOTH with a single commit.
>

I think the procedure is not the only issue; there is the organisation
of our bugzilla, which I think is to a major extent responsible for the
past 'orphaning' of the STABLE. As HEAD and STABLE grow appart, the bugs
will too, and we need to have a clear policy on how bugs are going to be
filed, which we did not have int he past. I have the following suggestions:

(1) I find the bug category CVS-HEAD near useless, because the CVS head
changes all the time. We have bugs filed 5 years ago against CVS-HEAD. I
think the CVS-HEAD should be removed from bugzilla's list. Instead HEAD
should be tagged periodically, say on fortnightly basis, and the version
number bumped up and added to bugzilla, so bugs against HEAD can always
be filed against a specific version number.

(2) The HEAD bugs should be periodically combed, and the version number
updated if a given bug persists. This would make it possible to gage the
bug activity for each bug without having to open the bug and scroll down
the bottom to see when was the last time someone updated it. The
periodic review process would also allow us to close bugs that 'fixed
themselves' as we go and avoid bugs that have been open for years
without any activity; it would also mean that the developer to whom the
bug was assigned would get more frequent reminders that he has not dealt
with it yet. (While this kind of review happens because some folk do
review bugs periodically, I think this should be formalised and there
should be someone who is formally in charge of this process, the
Bugzilla Maintainer.)

(3) Bugs that impact both HEAD and STABLE should be filed as two
separate bugs against each version and the bug against STABLE should be
marked as blocking the HEAD bug, so that bug against HEAD cannot be
closed until the STABLE bug is closed. While this will increase bugzilla
count, it is necessary to be able to track bugs properly. In the past we
would just have bugs filed against HEAD and closing the bug reports when
fixed in HEAD, leaving the stable maintainer to do the digging and
trying to workout what and when should be backported; this is
contraproductive.

(4) The developers need to take greater ownership of the STABLE branch.
I am guilty of just working on the HEAD in the past and leaving others
to worry about STABLE, and I am not alone. My feeling is that the core
developers should all maintain local copies of both STABLE and HEAD;
bugs filed against STABLE should be fixed in STABLE, bugs filed against
HEAD should be fixed in HEAD, bugs filed against both should be fixed by
the same person in both. The role of the STABLE maintainer should be
mainly to make decissions when it comes to fixing bugs that require more
complex changes, such as chnages in public APIs. It would be up to the
STABLE maintainer to decide that certain bugs fixed in HEAD could be
marked as WONTFIX for STABLE.

(5) There should be clear timetable for the next (i.e., 2.4) stable
release, which would include a date after which only P1 critical bugs
(easily reproducible crashers) would be fixed in STABLE. I think in the
2.0 cycle too much effort was put into maintaining the STABLE branch in
the run up to the 2.2. release.

(6) 2.4 should be released no later than July 2005. We have to fix the
list of features to be added, with developers assinged to them now and
stick to it.

(6) We should do frequent avertised pre-releases of the HEAD from early
on in the development cycle to increase bug reporst filed in the
development stage.

Tomas
Received on Wed Dec 29 13:07:17 2004