On Mon, 2004-11-08 at 09:51 -0500, Hubert Figuiere wrote:
> == Correct use of branching ==
>
> We have been using branches incorrectly. The first major mistake was
True.
> that we did fix bug from the STABLE release to HEAD and then backport.
> This process was really time consuming and was a real pain to follow
> because we had to go thru all the changes. Sometime we just ended up
> fixing things twice.
I think you give far too much weight to this as a problem, and have the
definitely the wrong solution.
> This is plain wrong. We should fix STABLE bugs into the STABLE branch
> and then with merging, the later branches would get them for free. See
> the next part for the correct use of CVS and how this can work
> seamlessly.
>
> We should also branch more often. For example, 2.2 is in feature freeze.
> We should already have branched for release, fixed all the bugs we want
> for the release in there, and eventually had new cool features in HEAD.
>
> In short, branch at feature freeze.
The problem isn't the logistics of it, it's that developers invariably
use stable-branching as an excuse to abandon that branch. That's why we
aren't branching at 2.2.0.
> Then merge often to all the subsequent branches in order. We should
> always merge from the older branch to the latest, by order, and not skip
> any unless they are considered to be dead. The elderness of the branch
> is the determined by the date of the branchpoint.
>
> Here is a nice ACSII art to explain this:
>
> /--------- 2.0 /-------- 2.4
> / /
> ======================================================> HEAD (the trunk)
> \
> \ ------ 2.2
>
> We merge 2.0 to 2.2, then 2.2 to 2.4, then 2.4 to HEAD. The would mean
> we still maintain 2.0, that 2.2 has been released and that 2.4 is in
> feature freeze about to be release. Off course we don't.
You are simply ignoring that correct use of branching means you develop
invasive or large new features in the branch, get it working and fix it
there, and merge into mainline when it is no longer a threat to the
continuation of concurrent development. This is also why you keep
branches separate and localized - you don't develop rc features and gsf
dependencies in the math branch because then you cannot simply merge
them into mainline when they are ready, you have to create an individual
patch (as I've done for rc) and merge portions manually. We happen to
be lucky that the rc code is relatively localized, and not dependent on
the other changes in that branch, as this would not be possible and they
would have to wait on the completion of math support before rc could be
tested. You cannot, _cannot_, _CANNOT_ merge broken branches into
mainline, it stalls concurrent testing and development.
> == Correct use of CVS ==
>
> For a long time we have not been using CVS the best way. CVS as some
> hugd desing drawbacks that can be worked around by some sane practice.
Something to that effect - it really is much more PEBCK and much less
design flaw. There are some minor issues, yes, but nothing devastating
or not circumventable.
> Branching
> ---------
>
> When branching, we must set a tag for the tree we want branch first.
> Basically if we want to branch MY-STABLE-BRANCH of HEAD that involve
> doing the following:
>
> cvs rtag -r HEAD MY-STABLE-BRANCH_branchoint
> cvs rtag -b -r MY-STABLE-BRANCH_branchoint MY-STABLE-BRANCH
>
> We did not do the first, so we can NOT know exactly when we branched.
> This is because of CVS and the way i merge branches (per file). Tagging
> the branchpoint tag the tree at the point so we can always start from
> here.
That's simply not the case. You already have a date for the point of
branch, and if you'd read the docs on cvs' interpretation of symbols
you'd realize that the way a sticky tag works is that you can reference
the point of tag or the last merge using the branch symbol.
> Merging
> -------
>
> Then, for merging we must always have a tag indicating the the last time
> we merged.
No. Like I said, you simply don't. You're trying to compensate for
inadequacy btwn chair and keyboard by increasing administrative
overhead.
> == Correct use of bugzilla ==
>
> We have been using bugzilla almost correctly, but the few things I saw
> that were not correct should be avoided:
No, we have not been using it almost correctly. But we have been using
it, at least.
> Re-assigning branch specific bugs to maintainer because you only work in
> HEAD is just wrong. If the bug has been assigned to you, it is likely
> because it is your area.
That was an isolated incident of a certain developer not thinking
straight. Don't let it skew your personal thoughts on the course of
development. You are right that it most certainly should not have
happened.
> Closing because because they are fixed in HEAD, bug not in STABLE,
> because either they are to be backported or can't be fixed.
> -In the first case, bug should have been fixed in STABLE, then merged
> later during the merging process described above.
> -In the second case, it should be attempted to fix in STABLE. If it is
> not possible, then we should open a separate bug (ah, I miss the "clone"
> feature) and annotate it as STABLE only.
You're sortof right on this.
- STABLE bugs should NOT be closed becaus we think they work in
mainline. That is correct.
- You DO NOT need to open a separate report. We have a policy of
annotation that allows us to keep bugs open but designated branch-only.
- Bugs existing only in an overdiverged branch should be marked WONTFIX
only after exhaustive work by the branch maintainer to backport or
reimplement the fix, as I did when I backported a number of fixes which
occurred after the branch was overdiverged. It was not that hard, it
just requires not being lazy.
> And fix the bug for the oldest branch it has been reported against so
> that we can have it in the largest number of releases.
You really aren't thinking this through quite enough IMNSHO. What
you're saying is to reopen 1-0-STABLE for our beos users (-:
> == Implement unit testing and regression testing ==
> We should implement unit testing for AbiWord. For example; all the code
Amen.
> Off course all these test should run automatically (makefile target),
> and be run under various memory checker. On UNIX that wou
I think you got cut off, but yes, autotest is your friend.
> We should not release anything without a successful run of both test
> suite.
Well, you're oversimplifying again, but it's the right idea.
> Please, feel free to comment.
Natürlich.
Invasive and large new features happen in branches. They are fixed in
branches, and then merged into mainline. Branches are independent (you
do not implement GSF IO, MathView, RC, unitlessness, and other features
in the same branch - it makes them all interdependent).
I will not allow math to be merged until it is fixed and ported to the
point where it will not stall concurrent testing and development. I
will eagerly merge the self-contained rc code once I get the final
thumbs-up from its lead dev, who has said he's some bugs to take care of
before it's quite ready. I will eagerly merge gsf io, once all the
build and dist kinks are worked out on all supported platforms (which I
discuss elsewhere). I will eagerly merge math once it will not stall
concurrent testing and development.
Invasive features get started and fixed in branch. If they are mostly
or entirely ready during stage1 (first two months after stable
branched), they can be considered for merge (and presumably merged).
Large features can get the third month if they are really really
thoroughly tested and ready to hit mainline running. After that, while
everything always depends on the coverage in-branch, the acceptable size
shrinks through the beginning of stage2 (the larger you are the more
in-branch coverage and defense, so to speak, you need to get merged).
You get two months to finalize and polish and the release is out on the
sixth, with no 'new features may cause problems', no 'sorry about the
regressions, it'll be better by the next milestone', no 'we couldnt test
this because the build was broken for two months', etc.
This way the coders get to work MORE on the fun feature implementation,
and the testers and users get MORE stable releases MORE often, and the
maintainer and qa doesnt want to kill the coders (ha ha, just
kidding...)
Regards
-MG
Received on Mon Nov 8 19:06:49 2004
This archive was generated by hypermail 2.1.8 : Mon Nov 08 2004 - 19:06:49 CET