On 12/21/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 12/20/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
>
> On Dec 20, 2006, at 7:57 PM, Craig McClanahan wrote:
> > In general, there's only one thing I'm surprised isn't here ... the
> > declaration that a vote to actually do a release is a majority
> > vote. That
> > might be implied by the general Apache policies, but I think it'd
> > be good to state that explicitly.
>
> I don't have a problem with stating it explicitly.
Wait, what "vote to actually do a release" ? At Struts the guidelines
say you post a release plan and/or announce your intentions on [EMAIL PROTECTED]
The only vote is on whether (and at what quality) to release the
package.
If we're going to have project-level bylaws [1] then we should add a
section with the procedure for changing the bylaws.
<snip/>
Agreed, do we really need these -- and if we do, they should also
specify what it takes to change them. The CTR suggestion for release
docs (below) also sounds good to me.
My understanding was:
a) Proposed artifacts land in staging repo
b) We vote before cp'ing to rsync repo and dist/ -- release vote
c) We have atleast one 'quality' vote, after sufficient time
Correct? Is there an announcement after (b), or do we wait till (c)?
-Rahul
Or we could just have project and release guidelines as part of the
project docs, under commit-then-review like everything else, which IMO
better fits how things actually happen. We're governed by the ASF
bylaws, but at the project level things are far more informal. I don't
think I've seen two releases done exactly the same way since I've been
here...
[1] Noel thinks they aren't necessary (and we removed that part of the
board resolution for Tiles):
http://mail-archives.apache.org/mod_mbox/incubator-general/200611.mbox/[EMAIL
PROTECTED]
--
Wendy
