httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <>
Subject Re: Voting Results
Date Thu, 07 Dec 1995 17:02:04 GMT
In reply to Ben Laurie who said
> Well, sort of, yes, but I imagine it will be a more fluid system. The whole
> point of using something like CVS is that all patches would _immediately_ apply
> to the "current" release, but could still be backed out later. Presumably the
> voting would apply only to snapshot releases (and these may have to be branch
> versions to allow patches to be taken out [for example, if they are buggy but
> _will_ ultimately be included]).

I think voting as a part of development will be a thing of the past but
see below.

> Patches by non-core members (to borrow the FreeBSD terminology) would have to
> either be picked up by a core member and incorporated, or go through a voting
> session (and then picked up by a core member).

Bad analogy, the FreeBSD core team is not a list of people who have commit

> Hmm ... I can see this might cause some headaches. Who will be core members?
> What will the criteria be? I can't imagine that it will work as a free-for-all;
> the good programmers will get totally pissed off with correcting the less-good
> programmers' bugs, for starters.

Those who have a track record of submitting patches and generally
knowing what they're doing should be given cvs access. Those without
access will have to send their patches to someone who has who will look
it over and decide whether to commit it. If a non-committer is consistently
submitting good work then give them cvs access so they can get on with it

There will be occasions when voting is required.

1) A new committer is proposed, in FreeBSD this is a "speak now or forever
hold your peace" type of vote. i.e. if no-one raises any objections the
person proposed gets access.

2) Someone is continually screwing things up and someone proposes that
access is revoked. This is a sensitive issue and some discussion followed
by a proper vote is needed.

> A (longish) question for CVS experts: one of the advantages of the current
> system of patching is that dodgy, controversial or complex patches get
> reviewed, and often amended, before being incorporated in the main code. This
> process can take quite a while. The equivalent method in CVS is to create a
> branch for the patch (I think!) - in practise is this easy enough to work?
> That is, if someone says "I intend to add an XYZ module, but it'll take a month
> and will probably break everything while I get it working" so we create a
> branch for XYZ, when we decide that it is cool to add to the main branch, how
> difficult is it to do, in practise?

It's laborious and I doubt it will be necessary for something as small as
Apache. People should not commit completely broken code, that's bad
practice and repeated offences will get your access revoked. People
make mistakes of course, but seriously screwing the sources so that
they plain don't build etc is bad.

If someone commits code that is fairly well tested on their particular
box then it's ok to go into the development branch. If it breaks other
people's boxes then *they* should find out why and commit the fix for
their system.

This is a much more fluid process than people are currently used to because
changes appear immediately and if you have a problem with a commit on
your particular box you can fix it straight away without waiting
a week for a vote cycle or whatever. What that tends to mean is that
if someone makes little oversights then they get fixed by someone
else within 5 mins of being detected.

The other thing is that, if you're working on major changes that may
take a month then you can do it on your own copy of the cvs tree
and other people's commits can be merged into your version relatively
painlessly so you can keep making your changes on top of the current
set of sources. When you have things developed to the point where
it's basically working and you think people should try it out then
cvs will merge all your changes back into the main tree.

Basically, there are very, very few occasions when a code freeze is
necessary. Tagging is more usefull for release engineering, i.e. you
tag a release so that down the road you can check out that release
from the tree and have an exact copy of how things looked at that point
in time. If you branch the tree you can also maintain fixes to a previous
release, like we intend doing for 1.0.

  Paul Richards. Originative Solutions Ltd.
  Phone: 0370 462071 (Mobile), +44 1225 447500 (work)

View raw message