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
