httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: CVS and generalising connections
Date Tue, 19 Dec 1995 17:24:26 GMT
> Paul wrote:
> >> Ok, it seems to me that:
> >> 1. The Apache Group delegates the development of an alpha version of 1.1
> >>    to a group of programmers. The programmers are those with write access to
> >>    the source.
> >
> >Umm, I'm not sure there's any distinction to be made here. You need to
> >clarify what you think the Apache group is since you make some
> >distinctions below too.
> >
> >> 2. Individuals must request access on the basis that they are making
> >>    significant changes; small modifications should be submitted as patches
> >>    in the normal way.
> >
> >> 
> >> 3. Module development should be somewhat separate; developers of
> >>    mop_imap, for example, should not need write access to the whole Apache
> >>    source for them to work efficiently.
> >> 
> >> 4. New user features should be voted on by the whole Apache Group.
> >
> >I'm really against all this voting nonsense. It's unecessarily bureaucratic
> >in that it takes more time to get a decision made than it does to do the
> >development and that is not something that bodes well long term.
> >
> >> 
> >> 5. New program developments (e.g. design of data structures) should be voted
> >>    on primarilty by the programmers, but with votes allowed from the Group
> >>    as a whole.
> >
> >As above.
> >
> >Like I said in a previous message, cvs doesn't remove the need for 
> >co-operation. If someone thinks a re-design of core data structures would
> >make things simpler/better/whatever, then I'd expect that they raise
> >the proposal in this list and have the technical issues discussed before
> >implementing any changes. There's really no need for all this formalistic
> >procedure though.
> Ok, as long as everyone knows what's expected of them.

I think it is worth preparing a document which says what is expected, if only
so we don't have to keep explaining it to newbies.

> >> 6. We should aim to get the module API finialised first, so that the module
> >>    developers can catch up.
> >
> >I don't think you're getting the idea about cvs.
> Clearly not.
> I'm getting the impression that once we start using CVS, then everybody
> connected with the development must use CVS. This sounds like a bad idea to
> me; doesn't this place an unnecessarily high obstacle in the way of new
> members of the group? (i.e. I had assumed above that only some of the
> Apache Group would be involved in this CVS thing.)

Not everyone should have to use CVS. Those who can't/don't want to can continue
to submit patches in the usual way. The patches would be applied by a CVS user,
instead of having to wait for a round of votes, releases, etc. The way that
CVS itself is managed is that every day a snapshot is taken of the current
tree, and made available for FTP on the CVS server, thus people who are not
CVS enabled can always get the latest version.

I'm all for getting the module API finalised first (meaning first _after_
installing CVS). I wasn't aware that it wasn't finalised (unless you mean this
connection abstraction stuff) - what's missing?

> >We should get cvs working as soon as possible. That way you have revision
> >history of all the changes that take place, which is something we don't
> >currently have, at least, not as easily.
> I'm all in favour of that! But when I tried to get the Group to use
> proper GNU-style ChangeLog entries, nobody was interested...

I don't remember that - before my time, perhaps?

>  David.



Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant        Fax:   +44 (181) 994 6472
and Technical Director      Email:
A.L. Digital Ltd,           URL:
London, England.

View raw message