httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Re: Voting rules/guidelines
Date Wed, 30 Aug 1995 20:25:20 GMT

I'll start refining this proposal..
>   1) anyone can say we need a new release, and make a call for patches
>   2) patches are uploaded to hyperreal with a unique id (number). The
>       number is fixed at time of uploading, and should be 1 more than
>       the highest existing patch id. 
>       Start at number XYZ01     for patches to release X.Y.Z,  e.g
>                       081101    for patch 1 to release 0.8.11

instead of the above as a filename convention, I think it better to
have the id as an extension, e.g


It's useful to have ids (and hence patches) which will stand the 
test of time, if only for future reference.

Patches should contain a couple of lines of description that can be used
at build time to document the change in the changelog (CHANGES file)

>   3) patches can be changed and/or withdrawn at any time 
>         withdrawn = just that, the patch is removed
>           changed = gets a new id and new patch uploaded.

Anyone can change *any* patch (multiple versions of the same fix can
be compared), but nobody can withdraw someone else's without permission.

Changes to a patch (typically a new patch with the old one withdrawn) should 
be clearly documented with comments in the patch header.

Patches should be created using 'diff -C3'

>   4) someone volunteers to collect the votes, another or same person 
>         volunteers to build the new version. The vote collector and
>         version builder agree on a voting deadline.
>   5) everyone can vote and comment as much as they want.
>   6) the vote deadline can be voted on too.
>   7) the release is assumed to be public unless vetoed.
>   8) no veto can be overruled, they can only be withdrawn.
>   9) the definition of a positive (aka +1) vote is that you've
>       a) looked at the patch (to see what it's about)
>       b) patched the file into the appropriate version
>       c) compiled the patched source
>       d) observed no side-effects  (not necessarily tested the patch's claims)
>  10) late votes..
>       positive votes: can be ignored or accepted at the discretion of the
>         person building the new version.
>       vetoes: ignored unless someone who voted positively publically
>         switches to a veto  (i.e. if you're late you have to convince someone)
>  11) a new version is built.
>         patches applied
>         version number incremented
>         changelog updated
>  12) the version builder can correct mistakes made during the build
>       e.g. removing a patch that wasn't supposed to be in or adding
>       one that was missed.
>  13) everyone is encouraged to download the new version and try it for
>       at least a day if the version is to be publically released.
>  14) if a new patch causes any problems a quick vote (*) should be taken on
>       whether to remove, replace or leave the patch as it stands. A majority
>       decission decides this vote.
>       (*) quick = about a day... enough time for everyone to read mail and
>       respond.

I'll HTML'ize these guidelines or whatever becomes of them at some point.


View raw message