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
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
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
