httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Kluft <>
Subject Re: voting
Date Thu, 08 Jan 1998 14:11:11 GMT
Observations and suggestions from a minor contributor...

If too many people had the ability to commit-then-review then things would
probably fall through the cracks unreviewed, which is a problem in the
opposite extreme of what Dean wants to solve.

However, considering who this request is coming from, I have to wonder if
some middle ground is possible.  If the voting members give Dean (or others
later on) a +1 to dive into 1.3 (or 1.2 if the votes turn up), this privilege
might entail the responsibility to report after the fact what actions were
taken using it.  And such a rare privilege probably should have an expiration
or renewal date to keep it rare.

This isn't something you'd want to do for just anyone.  But there must be
benefits to reducing restrictions on some of the project's most exceptional
contributors who have earned the privilege and can be trusted to live up
to the accompanying responsibilities.

Maybe call it the "temporary accelerated development" privilege or something
like that.  If the idea is adopted, it should probably be codified as an
amendment to the voting procedures.
Ian Kluft  KO6YQ PP-ASEL                                  Cisco Systems, Inc. (work) (home)          San Jose, CA

> From: Dean Gaudet <>
> Oh P.S. Insert Dean's standard rant about how much a waste of time
> preparing patches for voting, waiting for votes, and then committing them
> is.  And how much it detracts from the productivity of the project as a
> whole.  This has as much to do with the whole voting concept as it does
> with the lack of active people who have "voting rights". 
> Lately I'm moderately happy because a lot of folks are just giving my
> stuff +1 on a once-over read, especially when it's for the 1.3 tree.  But
> I still have to prepare patches to post, wait for votes, and then commit.
> Whereas CVS is designed to be used in a commit-then-review fashion, and
> we've got that wonderful cvs-to-mail gateway thing that lets us all see
> the commits as they happen. 
> I know for a fact there's a shitload more I would have done over the
> summer if we didn't work in this manner.  Big patches are just not welcome
> here, every time I post a non-trivial large patch I get complaints "wow
> that's big, it's scary" and getting votes for them is like extracting
> teeth.  So instead I waste time incrementally approaching a goal, or I
> just don't do the work I want to do.  For a current example of this see
> Martin's large EBCDIC patch which only I've voted on, and now it's out of
> date and Martin will have to update it again before anyone else will vote
> on it, and then folks will delay several weeks again, and it'll be out of
> date again... 
> We're the only free software project I'm aware of that works in this
> braindead fashion.  I am completely envious of the freedom that folks on
> other projects experience.  (In particular I track linux, squid, and some
> freebsd development.  For linux and squid they have frequently development
> releases, bugs are fixed quickly in the releases, features go in by the
> bucketloads.) 
> Yes, if you move to this model then the current CVS HEAD doesn't always
> work.  But, uh, so what?  If it doesn't work then fix it, or bitch at the
> author and stick with out of date code for a day or two.  That's how every
> other software project I've worked on behaves. 
> You know, in those cases where I've complained about aspects of other
> people's patches that bother me.  If we were in a commit-then-review
> situation I would have just fixed what bothered me after you committed.
> This saves time.  Words are not exact, code is exact. 
> Whatever. 

View raw message