Re: PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws
On 12/21/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: 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)? That's how it seemed to happen last time, but IIRC we never had a quality vote for Shale 1.0.3. http://mail-archives.apache.org/mod_mbox/shale-dev/200608.mbox/[EMAIL PROTECTED] "If it passes, we'll hold a quality vote later on." IMO, if we're voting on release quality, then every release needs to have a quality attached before it is offered to the public. So b) would default to a vote for alpha quality. It's up to the release manager, though. It could start at beta, or if it's a bugfix on a stable branch and we're confident in the build and release process, it could be voted GA immediately. -- Wendy
Re: PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws
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. 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
Re: PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws
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. 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
Re: PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws
On 12/20/06, Greg Reddin <[EMAIL PROTECTED]> wrote: On Dec 20, 2006, at 7:57 PM, Craig McClanahan wrote: > On 12/20/06, Greg Reddin <[EMAIL PROTECTED]> wrote: >> >> The Shale project currently does not have a bylaws document. I >> propose that we adopt the Struts bylaws[1] as the basis for our own >> bylaws document and make changes in the following areas: >> >> 1. Change all instances of "Struts" to "Shale". >> >> 2. Discuss the "Subprojects" section. Specifically, do we want >> subprojects to be the "unit of release"? > > > I think we want the *possibility* of this level of granularity, > although we > would also be able to exercise the right to release things > together. I > think we *need* this level of granularity to contemplate something > like > "shale-tiles is released as beta, but the rest is released as GA" > sort of > vote. Maybe we keep the idea of subprojects but take out the thing about them being a unit of release. And we could define unit of release differently if we feel like it needs to be defined. I would be comfortable saying a "unit of release" is a collection of artifacts that the PMC deems is ready for a release. That collection might include some subprojects and not others or it might include a cut of the entire Shale codebase. If we define it this way then we should probably state that a formal part of the release process is defining what artifacts will be in the release. That works for me ... especially when this is an essential decision anyway. Craig 3. Discuss the "Release Grade" section. Are we comfortable with the >> Struts definition of this section or would we like to refine it? > > > I'm OK with this in general ... the implication of "test before > voting", > though, implies to me that we can at least ask people on the dev > list to > "please go look at this test build and report back any problems." > Right? I think so. That sounds perfectly reasonable. > 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. Greg
Re: PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws
On Dec 20, 2006, at 7:57 PM, Craig McClanahan wrote: On 12/20/06, Greg Reddin <[EMAIL PROTECTED]> wrote: The Shale project currently does not have a bylaws document. I propose that we adopt the Struts bylaws[1] as the basis for our own bylaws document and make changes in the following areas: 1. Change all instances of "Struts" to "Shale". 2. Discuss the "Subprojects" section. Specifically, do we want subprojects to be the "unit of release"? I think we want the *possibility* of this level of granularity, although we would also be able to exercise the right to release things together. I think we *need* this level of granularity to contemplate something like "shale-tiles is released as beta, but the rest is released as GA" sort of vote. Maybe we keep the idea of subprojects but take out the thing about them being a unit of release. And we could define unit of release differently if we feel like it needs to be defined. I would be comfortable saying a "unit of release" is a collection of artifacts that the PMC deems is ready for a release. That collection might include some subprojects and not others or it might include a cut of the entire Shale codebase. If we define it this way then we should probably state that a formal part of the release process is defining what artifacts will be in the release. 3. Discuss the "Release Grade" section. Are we comfortable with the Struts definition of this section or would we like to refine it? I'm OK with this in general ... the implication of "test before voting", though, implies to me that we can at least ask people on the dev list to "please go look at this test build and report back any problems." Right? I think so. That sounds perfectly reasonable. 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. Greg
Re: PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws
On 12/20/06, Greg Reddin <[EMAIL PROTECTED]> wrote: The Shale project currently does not have a bylaws document. I propose that we adopt the Struts bylaws[1] as the basis for our own bylaws document and make changes in the following areas: 1. Change all instances of "Struts" to "Shale". 2. Discuss the "Subprojects" section. Specifically, do we want subprojects to be the "unit of release"? I think we want the *possibility* of this level of granularity, although we would also be able to exercise the right to release things together. I think we *need* this level of granularity to contemplate something like "shale-tiles is released as beta, but the rest is released as GA" sort of vote. 3. Discuss the "Release Grade" section. Are we comfortable with the Struts definition of this section or would we like to refine it? I'm OK with this in general ... the implication of "test before voting", though, implies to me that we can at least ask people on the dev list to "please go look at this test build and report back any problems." Right? 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. Thanks, Greg [1] http://struts.apache.org/dev/bylaws.html Craig
PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws
The Shale project currently does not have a bylaws document. I propose that we adopt the Struts bylaws[1] as the basis for our own bylaws document and make changes in the following areas: 1. Change all instances of "Struts" to "Shale". 2. Discuss the "Subprojects" section. Specifically, do we want subprojects to be the "unit of release"? 3. Discuss the "Release Grade" section. Are we comfortable with the Struts definition of this section or would we like to refine it? Thanks, Greg [1] http://struts.apache.org/dev/bylaws.html
