Re: gcc development schedule [Re: sharing libcpp between GDB and GCC]

[Tom Lord <lord@emf.net>]

	   Dan:

	   Because it causes things to stagnate on branches, while
	   attempting to meet the "high barrier" on the trunk.

Not necessarily.  It depends on your tools.  For this issue, the
relevant tools are the testing infrastructure and revision control
infrastructure.

Regarding testing, there seems to be two shortfalls.  One is in the
completeness of the existing test suite: at least one vendor finds it
necessary to supplement that test suite with tests they buy a license
for in order to obtain better coverage; beefing up the test suite
would give more developers more direct access to more thorough
testing.  The other issue is automation.  There are at least two
instances of vendors implementing their own infrastructures to grab
the head from the trunk and test that periodically in various ways
(and I suspect that there are, in fact, several more than two); a
better approach would be to collect those automated testing
infrastructures under a common (automated) interface and make them
available to lots of branches (even branches not maintained by people
with write access to the main repository).

Regarding revision control, there can be a queue from branches
(including branches outside the main repository) to the trunk.  For
most change sets, propagation along that queue, passing through the
testing barrier, can be automated.  BitKeeper seems to be up to that
already.  arch and Subversion are both close behind.  Even where you
might want to inject a human conducted review into the queue process,
tools infrastructure can help simplify that process and reduce the
reviewer's action from "check in these changes" to "click the
thumbs-up/down button".

	In addition, it assumes there is no overhead associated with
	maintaining a branch (and let's not get into a discussion
	about arch or anything

Actually, I've been trying to avoid the topic of merging tools
precisely because the issue is bigger than arch.  Yes, I think arch
can be a big help here -- but so, perhaps, can Subversion or
BitKeeper.  Heck, there's even a GCC maintainer who contributes to
Subversion.  If the discussion ever reaches the stage of contemplating
choices of revision control system, I'll be happy to help make the
case for arch.  At this stage, in this context, it's probably not
important.


       Sorry, but nobody is going to merge a complete rewrite of the
       C++ parser, for instance, to the head, without *any*
       difficulties whatsover.

Using _any_ modern system, the merge can be worked out on a branch and
the transition to the trunk automated.

One advantage of "hierarchical software management" is that it allows
difficult merge instances to be distributed down the hierarchy --
making it easier for more than just maintainers with write access to
work on them.  Core maintainer bandwidth can be _increased_ by
effective branching, in contrast to the expectation expressed
there and elsewhere in your message.

-t