PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws

[Greg Reddin <gr...@apache.org>]

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

[Craig McClanahan <cr...@apache.org>]

On 12/20/06, Greg Reddin <gr...@apache.org> wrote:
>
>
> On Dec 20, 2006, at 7:57 PM, Craig McClanahan wrote:
>
> > On 12/20/06, Greg Reddin <gr...@apache.org> 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

[Wendy Smoak <ws...@gmail.com>]

On 12/21/06, Rahul Akolkar <ra...@gmail.com> 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/%3Cf8b39ace0608201809i645191cfp2a34f2af51770206@mail.gmail.com%3E
"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

[Rahul Akolkar <ra...@gmail.com>]

On 12/21/06, Wendy Smoak <ws...@gmail.com> wrote:
> On 12/20/06, Greg Reddin <gr...@apache.org> 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 dev@.
> 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/%3CNBBBJGEAGJAKLIDBKJOPMENILJAC.noel@devtech.com%3E
>
> --
> Wendy
>

Re: PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws

[Wendy Smoak <ws...@gmail.com>]

On 12/20/06, Greg Reddin <gr...@apache.org> 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 dev@.
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/%3CNBBBJGEAGJAKLIDBKJOPMENILJAC.noel@devtech.com%3E

-- 
Wendy

Re: PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws

[Greg Reddin <gr...@apache.org>]

On Dec 20, 2006, at 7:57 PM, Craig McClanahan wrote:

> On 12/20/06, Greg Reddin <gr...@apache.org> 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

[Craig McClanahan <cr...@apache.org>]

On 12/20/06, Greg Reddin <gr...@apache.org> 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