Proposal for tracking our work

[Da...@lotus.com]

Branches in CVS, or any code-management system, are costly in terms of
the attention and maintenance they require. In my last message on this
thread, I argued that we should expect to have some in Xalan, and plan
on that happening, rather than just dreading the inevitable. But you
should certainly count me among those who would like to minimize the
extent of branching in CVS.

It appears that the Bugzilla analog is the "component" field, or that
"component" can at least be used to represent branches. Could we get
some comments from an experienced Bugzilla user? Scott Boag's idea is
that Bugzilla can serve as an adequate work-management system, which
implies that status changes (notably, bug fixes) can be confined to a
branch.

If CVS and Bugzilla can support branching in a compatible way, I would
then propose that we pre-define two branches for each flavor (Java and
C++) of Xalan. We would only activate a branch when we know that some
experimental work will probably ignore stability concerns for a time
period that conflicts with a required stability release. When you think
about it, the main/trunk code stream can support experimental work
until someone says "we need to have a release, SOON, whose goal is to
improve stability by gathering up the accumulated bug fixes and not
including risky new features." So the experiments don't drive us to
branch, stability requirements do. I think our experiments will fall
into two categories: performance improvements and enhancements to
the (Xalan-specific and hence namespaced) feature set. I hope that all
enhancements for internationalization can be characterized as minor bug
fixes or under the "new feature" category, but non-American readers are
invited to SPEAK UP NOW if you disagree.

The plan: the MAIN code stream will always exist and will always have
the goal of accumulating bug fixes and working toward better stability.
The PERFormance and FEATure (and INTL if necessary) branches will be
mapped out for temporary activation. When an experiment is underway
that could de-stabilize Xalan at an awkward time, it will be shunted
off to the appropriate pre-defined branch, which will be activated
until a later merge with MAIN. After the merge, the bugzilla reports
for that component will be cleared away or archived, but the component
stays for future activation. This signals to the contributors that we
want collaboration toward one of the permanent goals (stability, more
features, better perforamnce) rather than rampant splintering. When
someone comes along with an idea or patch near a deadline for a
stability-driven release, we would have more options than just
postponing the commit.

As you can see, the above plan allows releases from the branches for
experimental versions, but it favors trunk (stability-driven) releases.
If we get to a stage where we want an experiemntal release, there are
other aspects of release management that should be discussed.
.................David Marston