On Thu, Sep 07, 2000 at 10:48:57PM -0600, Nathan Torkington wrote:
> Michael G Schwern writes:
> > There's one solution, now that we have a nifty source control stuff.
> > Branch like mad! Feature creep should be discouraged, but if a group
> > wants to go off and work on something which isn't going to make it
> > into the next release they can branch and play.
>
> Adding a new feature would require documentation, test cases, and
> analysis of how the feature fits in with the umpty-zillion other
> features in Perl, not just code. I figure the lead coder can look
> at progress, look at the new feature, and decide whether it's worth
> it on a case by case basis.
>
> But I am cool to the idea that we should lose good coders to
> potentially bad ideas. Explore those ideas later, get perl6 working
> first.
Its not good feature/bad feature. Its more like parallel development.
Take, for example, threading. The tailors decide they need to
overhaul the guts of threading yet again, but the Pumpking is
concerned that it would hold up the next release to wait for the new
threading code to be stable. So a branch is made and the threading
boys go off and play with their threads and the rest of Perl gets on
with it. A release or two later, the threading branch is ready and is
rolled into the main release.
In effect, instead of having one development track, we could have many
development tracks, each focused on a single feature, or small group
of features. This should make work easier, because on each track only
one thing is changing, so its easier to track down new bugs.
There is a problem of integration. Each track will have to pay
attention to what the others are doing, and they can't go too long
without merging back into the main branch else there will be too many
conflicts. But I think overall the problems of bugs via features
interacting will be lowered due to the fact that when branches are
merged back into the main that branch has already been tested on its
own and works.
The same patching and testing rules would apply across all "official"
branches (if somebody wants to go nuts on their own we can't really
stop them) and QA would keep an equal eye on them all. In effect, all
feature patches would happen in branches, and nothing but bug fixes
should appear in the main.
In fact, I'd almost go so far as to say a new branch should be made
for each bug to be fixed. These branches would be short lived, but
they would help to consolidate the series of bug fix patches which is
often applied to fix a single bug. Make them easier to track and know
when a bug has been officially closed (the branch has been merged).
Of course, all this comes from someone who doesn't know how to branch
in CVS.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in <[EMAIL PROTECTED]>
