Bylaws and Releases

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

Having volunteered as release manager Struts Action 1.3.1, I'm reading
the instructions. :)

The bylaws [1] say that release plans must be announced on the dev
list and that each issue is decided by lazy majority.

I interpret this to mean that I can [ANNOUNCE] the release plan and
the intended date, then proceed with tagging the repository and
creating the test build, as long as -1's do not outnumber +1's.  In
practice, of course, any -1 is likely to stop the process.

But that's not what has happened for recent releases-- [VOTE]s have
been called to confirm the release plans themselves, and then again
for the quality of the proposed releases.

Am I interpreting the bylaws correctly?  Is there an unwritten rule
about when you should call a vote on a release plan?

[1] http://struts.apache.org/bylaws.html

Thanks,
--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Bylaws and Releases

[Ted Husted <te...@gmail.com>]

On 3/9/06, Wendy Smoak <ws...@gmail.com> wrote:
> Sorry, but I'm going to keep quoting the bylaws until I understand how
> this works.
>
> " After a proposed release is built, it must be tested and classified
> before being released to the general public. The proposed release may
> be assigned "Alpha", "Beta" or "General Availability" classifications
> by majority vote. Once a release is classified by the PMC Members, it
> may be distributed to the general public on behalf of the Foundation.
> "
>
> That says the "Alpha" label cannot be applied to a release without a
> vote.  Before that, it's only a 'proposed release'.  (The notion of
> 'test build' is not in the bylaws.)  It also says that alpha releases
> can be distributed.
>
> I have an ulterior motive in wanting to preserve the "official" alpha
> designation.  MyFaces is waiting on another Shale release-- alpha is
> fine, but it needs to be a sanctioned release so it can go in the
> Maven repository.
>
> Thanks for your patience. :)

The notion of a test-build stems from the phrase "After a proposed
release is built". We've been using "test build" as a synonym for
"proposed release".

My suggestion would be that we use three classifications

* Alpha Build
* Beta Release
* GA Release

when a committer tags and rolls a build pursuant to a release plan,
the build could be granted a default "Alpha Build" status by lazy
consensus. After announcing the Alpha Build to the dev@ list, we could
vote to change the status to a Beta or GA Release. Once a build is
sanctioned by the PMC, then we could announce it to the user list.

As to the "ulterior" motive, if something is going to be sanctioned,
we might as well sanction it as a Beta.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Bylaws and Releases

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

On 3/10/06, Greg Reddin <gr...@apache.org> wrote:
>
>
> On Mar 9, 2006, at 7:02 PM, Wendy Smoak wrote:
>
> > That says the "Alpha" label cannot be applied to a release without a
> > vote.  Before that, it's only a 'proposed release'.  (The notion of
> > 'test build' is not in the bylaws.)  It also says that alpha releases
> > can be distributed.
>
> I think "proposed release" and "test build" essentially mean the same
> thing, though I might prefer the use of "proposed release" a bit
> simply because it makes it very clear that the build is not yet a
> release.  But I think that last phrase is the point.  It matters
> little what we call it on the user list as long as we make it very
> clear that it is not a release.


We've been using "test build" for a while, we should stick with it.

I'd prefer to see us announce them on both dev and user lists.

As an aside, do you think that most people who are interested in
> testing and playing with stuff like this would be subscribed to the
> dev@ list anyway?  If so, does the announcement really need to go to
> the user@ list before it becomes a release?


It would be cool if that were true (all of the interested parties would be
subscribed to dev), but I suspect it is not. Indeed, if all you care about
is knowing when cutting edge stuff might be worth trying out, and don't care
so much about influencing what is changing (other than perhaps submitting
some Bugzilla tickets), that's an understandable approach to reducing
mailbox bloat.

Greg


Craig

Re: Bylaws and Releases

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

On Mar 9, 2006, at 7:02 PM, Wendy Smoak wrote:

> That says the "Alpha" label cannot be applied to a release without a
> vote.  Before that, it's only a 'proposed release'.  (The notion of
> 'test build' is not in the bylaws.)  It also says that alpha releases
> can be distributed.

I think "proposed release" and "test build" essentially mean the same  
thing, though I might prefer the use of "proposed release" a bit  
simply because it makes it very clear that the build is not yet a  
release.  But I think that last phrase is the point.  It matters  
little what we call it on the user list as long as we make it very  
clear that it is not a release.

As an aside, do you think that most people who are interested in  
testing and playing with stuff like this would be subscribed to the  
dev@ list anyway?  If so, does the announcement really need to go to  
the user@ list before it becomes a release?

Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Bylaws and Releases

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

On 3/9/06, Ted Husted <te...@gmail.com> wrote:

> If we are going to announce unsanctioned builds to user@, then,
> please, let's at least call them *ALPHA* builds, so that these
> unilateral "trial balloons" are not confused with an actual beta
> release, approved by the PMC.

Sorry, but I'm going to keep quoting the bylaws until I understand how
this works.

" After a proposed release is built, it must be tested and classified
before being released to the general public. The proposed release may
be assigned "Alpha", "Beta" or "General Availability" classifications
by majority vote. Once a release is classified by the PMC Members, it
may be distributed to the general public on behalf of the Foundation.
"

That says the "Alpha" label cannot be applied to a release without a
vote.  Before that, it's only a 'proposed release'.  (The notion of
'test build' is not in the bylaws.)  It also says that alpha releases
can be distributed.

I have an ulterior motive in wanting to preserve the "official" alpha
designation.  MyFaces is waiting on another Shale release-- alpha is
fine, but it needs to be a sanctioned release so it can go in the
Maven repository.

Thanks for your patience. :)
--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Bylaws and Releases

[Ted Husted <te...@gmail.com>]

On 3/9/06, Martin Cooper <ma...@apache.org> wrote:
> Why are you bringing this up now? This is a rehash of a discussion we had
> years ago. The first announcement of a Test Build was sent to the user list
> in February 2004, over two years ago. I'm not aware of problems over the
> last two years that would lead us to need to rehash it all over again now.

Heretofore, the PMC was voting on the release plan.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Bylaws and Releases

[Paul Benedict <pa...@yahoo.com>]

If I remember correctly, Tomcat announces each release publically and calls
them "alpha" before GA. I think Ted has a good point, but I don't want
to quibble over "alpha" or "test" since, as Wendy pointed out,
it is a release. As long as the user list knows it's not an official
version, which was Martin's comment, I think there will be little 
confusion.

--- Wendy Smoak <ws...@gmail.com> wrote:

> On 3/9/06, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> 
> > I agree with Martin.
> 
> Me, too.
> 
> We need to fix /releases.html, which is inconsistent with recent
> history and sentiment. :)
> 
> " The test build can be posted to the internal distribution directory
> (svn.apache.org/struts/) and announced to the Struts DEV and PMC lists
> (only!). Do not announce a test build on any other Apache lists or
> link to it from an Apache website. "
> 
> Back to my motives:  Shale likely won't make it past alpha until
> Standalone Tiles does.
> 
> Just so nothing comes up at the last minute, the as-yet-unnanounced
> intent is to do another Shale build, and assuming it is graded alpha,
> to distribute it from www.apache.org/dist/java-repository, which will
> replicate to ibiblio.  The way things stand, there will be no 'alpha'
> modifier in the filenames, just 'shale-test-1.0.1.jar', etc.
> 
> Are there any objections to distributing an alpha release in this manner?
> 
> Thanks,
> --
> Wendy
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Bylaws and Releases

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

On 3/10/06, Ted Husted <te...@gmail.com> wrote:
>
> On 3/9/06, Wendy Smoak <ws...@gmail.com> wrote:
> > We need to fix /releases.html, which is inconsistent with recent
> > history and sentiment. :)
> >
> > " The test build can be posted to the internal distribution directory
> > (svn.apache.org/struts/) and announced to the Struts DEV and PMC lists
> > (only!). Do not announce a test build on any other Apache lists or
> > link to it from an Apache website. "
>
> +1
>
>
> > Back to my motives:  Shale likely won't make it past alpha until
> > Standalone Tiles does.
> >
> > Just so nothing comes up at the last minute, the as-yet-unnanounced
> > intent is to do another Shale build, and assuming it is graded alpha,
> > to distribute it from www.apache.org/dist/java-repository, which will
> > replicate to ibiblio.  The way things stand, there will be no 'alpha'
> > modifier in the filenames, just 'shale-test-1.0.1.jar', etc.
>
> Ummm, I don't believe we want to start using modifiers again. It would
> just be shale-1.0.1.jar. The quality grade (including no grade) is
> extracurricular from the distribution file name, allowing us to adjust
> the grade based on actual experience.


+1.

Now, if we were able to roll a tiles-1.0.0 first, and by some miracle
> that ever went GA, then, from what you have said, then shale-1.0.1
> might be able to go GA too.


Standalone Tiles is not very far into the proposed refactoring, and it would
be a shame to miss out on the opportunity to clean that stuff up before a GA
release.

-Ted.


Craig

---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Bylaws and Releases

[Ted Husted <te...@gmail.com>]

On 3/9/06, Wendy Smoak <ws...@gmail.com> wrote:
> We need to fix /releases.html, which is inconsistent with recent
> history and sentiment. :)
>
> " The test build can be posted to the internal distribution directory
> (svn.apache.org/struts/) and announced to the Struts DEV and PMC lists
> (only!). Do not announce a test build on any other Apache lists or
> link to it from an Apache website. "

+1


> Back to my motives:  Shale likely won't make it past alpha until
> Standalone Tiles does.
>
> Just so nothing comes up at the last minute, the as-yet-unnanounced
> intent is to do another Shale build, and assuming it is graded alpha,
> to distribute it from www.apache.org/dist/java-repository, which will
> replicate to ibiblio.  The way things stand, there will be no 'alpha'
> modifier in the filenames, just 'shale-test-1.0.1.jar', etc.

Ummm, I don't believe we want to start using modifiers again. It would
just be shale-1.0.1.jar. The quality grade (including no grade) is
extracurricular from the distribution file name, allowing us to adjust
the grade based on actual experience.

Now, if we were able to roll a tiles-1.0.0 first, and by some miracle
that ever went GA, then, from what you have said, then shale-1.0.1
might be able to go GA too.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Bylaws and Releases

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

On 3/9/06, Niall Pemberton <ni...@blueyonder.co.uk> wrote:

> I agree with Martin.

Me, too.

We need to fix /releases.html, which is inconsistent with recent
history and sentiment. :)

" The test build can be posted to the internal distribution directory
(svn.apache.org/struts/) and announced to the Struts DEV and PMC lists
(only!). Do not announce a test build on any other Apache lists or
link to it from an Apache website. "

Back to my motives:  Shale likely won't make it past alpha until
Standalone Tiles does.

Just so nothing comes up at the last minute, the as-yet-unnanounced
intent is to do another Shale build, and assuming it is graded alpha,
to distribute it from www.apache.org/dist/java-repository, which will
replicate to ibiblio.  The way things stand, there will be no 'alpha'
modifier in the filenames, just 'shale-test-1.0.1.jar', etc.

Are there any objections to distributing an alpha release in this manner?

Thanks,
--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Bylaws and Releases

[Niall Pemberton <ni...@blueyonder.co.uk>]

I agree with Martin.

Niall

----- Original Message ----- 
From: "Martin Cooper" <ma...@apache.org>
Sent: Friday, March 10, 2006 1:33 AM


On 3/9/06, Ted Husted <te...@gmail.com> wrote:
>
> On 3/9/06, Martin Cooper <ma...@apache.org> wrote:
> > I do agree that we should make sure people understand that it's not a
> > release, but I don't think we need to assume that the user@ audience is
> too
> > dumb to recognise the distinction between a Test Build and a Release.
>
> I wouldn't use the word "dumb", but I do think it is cavalier for us
> to assume that most users are aware of the distinction between a "test
> build"  and a "beta release". The term "test build" is something we
> made up, and it's doubtful that many other people actually understands
> what it means.


Why are you bringing this up now? This is a rehash of a discussion we had
years ago. The first announcement of a Test Build was sent to the user list
in February 2004, over two years ago. I'm not aware of problems over the
last two years that would lead us to need to rehash it all over again now.

Whether a build is a "release" is an important distinction to an
> Apache project, and I would not want to make a practice of doing
> anything that might dilute the concept of an Apache Release. We
> understand that a test-build is not a release, but people seeing an
> announcement on user@ might not share that understanding.


We've been doing it for two years. It's not like it's a new concept. And our
messages have been very explicit about a Test Build not being a Release.

If people are not ready to vote a test-build to GA, then there is no
> harm in voting it beta first and announcing it. (Especially since we
> aren't voting on the plans.) We can vote on a build as many times as
> we like, to either upgrade or downgrade the quality.


I think you're missing my point here. I'm not talking about people on dev
not ready to vote to GA, but rather that we would be limiting the feedback
we gain on the test build before we have to vote on it. IMHO, the more
opportunity for feedback _before_ the vote, the better off we are.

If we are going to announce unsanctioned builds to user@, then,
> please, let's at least call them *ALPHA* builds, so that these
> unilateral "trial balloons" are not confused with an actual beta
> release, approved by the PMC.


This would be much worse, in my opinion. Trying to explain to people that an
Alpha build is not a release but a Beta build is a release is going to be
*much* more confusing to people than explaining that a Test Build is not a
release. To have Alpha and Beta designate builds of different legal status
would be very bad.

And besides, as Wendy pointed out, an Alpha _is_ a release, and would
therefore need a vote from the PMC. The whole point of Test Builds is so
that we can push a build out for experimentation without making any up-front
declaration as to its quality. It also empowers all of the Struts committers
to lead us down the "release early, release often" path, which is A Good
Thing.

The scheme we've had in place for the last two years is working just fine.
If it ain't broke, don't fix it. And IMO this is one thing that just ain't
broke.

--
Martin Cooper


(And, here, I'm just speaking in the general case, not to any specific
> build.)
>
> -Ted.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Bylaws and Releases

[Martin Cooper <ma...@apache.org>]

On 3/9/06, Ted Husted <te...@gmail.com> wrote:
>
> On 3/9/06, Martin Cooper <ma...@apache.org> wrote:
> > I do agree that we should make sure people understand that it's not a
> > release, but I don't think we need to assume that the user@ audience is
> too
> > dumb to recognise the distinction between a Test Build and a Release.
>
> I wouldn't use the word "dumb", but I do think it is cavalier for us
> to assume that most users are aware of the distinction between a "test
> build"  and a "beta release". The term "test build" is something we
> made up, and it's doubtful that many other people actually understands
> what it means.


Why are you bringing this up now? This is a rehash of a discussion we had
years ago. The first announcement of a Test Build was sent to the user list
in February 2004, over two years ago. I'm not aware of problems over the
last two years that would lead us to need to rehash it all over again now.

Whether a build is a "release" is an important distinction to an
> Apache project, and I would not want to make a practice of doing
> anything that might dilute the concept of an Apache Release. We
> understand that a test-build is not a release, but people seeing an
> announcement on user@ might not share that understanding.


We've been doing it for two years. It's not like it's a new concept. And our
messages have been very explicit about a Test Build not being a Release.

If people are not ready to vote a test-build to GA, then there is no
> harm in voting it beta first and announcing it. (Especially since we
> aren't voting on the plans.) We can vote on a build as many times as
> we like, to either upgrade or downgrade the quality.


I think you're missing my point here. I'm not talking about people on dev
not ready to vote to GA, but rather that we would be limiting the feedback
we gain on the test build before we have to vote on it. IMHO, the more
opportunity for feedback _before_ the vote, the better off we are.

If we are going to announce unsanctioned builds to user@, then,
> please, let's at least call them *ALPHA* builds, so that these
> unilateral "trial balloons" are not confused with an actual beta
> release, approved by the PMC.


This would be much worse, in my opinion. Trying to explain to people that an
Alpha build is not a release but a Beta build is a release is going to be
*much* more confusing to people than explaining that a Test Build is not a
release. To have Alpha and Beta designate builds of different legal status
would be very bad.

And besides, as Wendy pointed out, an Alpha _is_ a release, and would
therefore need a vote from the PMC. The whole point of Test Builds is so
that we can push a build out for experimentation without making any up-front
declaration as to its quality. It also empowers all of the Struts committers
to lead us down the "release early, release often" path, which is A Good
Thing.

The scheme we've had in place for the last two years is working just fine.
If it ain't broke, don't fix it. And IMO this is one thing that just ain't
broke.

--
Martin Cooper


(And, here, I'm just speaking in the general case, not to any specific
> build.)
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Bylaws and Releases

[Ted Husted <te...@gmail.com>]

On 3/9/06, Martin Cooper <ma...@apache.org> wrote:
> I do agree that we should make sure people understand that it's not a
> release, but I don't think we need to assume that the user@ audience is too
> dumb to recognise the distinction between a Test Build and a Release.

I wouldn't use the word "dumb", but I do think it is cavalier for us
to assume that most users are aware of the distinction between a "test
build"  and a "beta release". The term "test build" is something we
made up, and it's doubtful that many other people actually understands
what it means.

Whether a build is a "release" is an important distinction to an
Apache project, and I would not want to make a practice of doing
anything that might dilute the concept of an Apache Release. We
understand that a test-build is not a release, but people seeing an
announcement on user@ might not share that understanding.

If people are not ready to vote a test-build to GA, then there is no
harm in voting it beta first and announcing it. (Especially since we
aren't voting on the plans.) We can vote on a build as many times as
we like, to either upgrade or downgrade the quality.

If we are going to announce unsanctioned builds to user@, then,
please, let's at least call them *ALPHA* builds, so that these
unilateral "trial balloons" are not confused with an actual beta
release, approved by the PMC.

(And, here, I'm just speaking in the general case, not to any specific build.)

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Bylaws and Releases

[Martin Cooper <ma...@apache.org>]

On 3/9/06, Ted Husted <te...@gmail.com> wrote:
>
> I would agree that we don't need to vote on Release Plans that have
> been maintained for three or more days in plain sight on the wiki.
>
> But, I would suggest that we not announce "test builds" to the user
> list until the distribution has passed a qualty vote and earned a beta
> or GA designation.


I disagree. I believe that as long as the subject line is something like:

[ANNOUNCEMENT] Struts 1.2.9 Test Build

and the message makes it clear that a test build is not a release, we
actually gain from telling people that it's available, because some
proportion of the community will pick it up and give it a whirl. This is
what we've (or at least I've) done in the past, and it has worked out fine.

If we only announce it to the dev list, we increase the likelyhood that we
end up with a build that we label GA that ends up not being GA because bugs
weren't found until a wider audience was exposed to it.

I do agree that we should make sure people understand that it's not a
release, but I don't think we need to assume that the user@ audience is too
dumb to recognise the distinction between a Test Build and a Release.

--
Martin Cooper


An announcement to the user list makes the build seem like a Release,
> which it is not. The ASF board does want there to be at least three
> binding +1's and a positive majority before we call something an
> Apache Release.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Bylaws and Releases

[Ted Husted <te...@gmail.com>]

I would agree that we don't need to vote on Release Plans that have
been maintained for three or more days in plain sight on the wiki.

But, I would suggest that we not announce "test builds" to the user
list until the distribution has passed a qualty vote and earned a beta
or GA designation.

An announcement to the user list makes the build seem like a Release,
which it is not. The ASF board does want there to be at least three
binding +1's and a positive majority before we call something an
Apache Release.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Bylaws and Releases

[Martin Cooper <ma...@apache.org>]

On 3/6/06, Wendy Smoak <ws...@gmail.com> wrote:
>
> Having volunteered as release manager Struts Action 1.3.1, I'm reading
> the instructions. :)
>
> The bylaws [1] say that release plans must be announced on the dev
> list and that each issue is decided by lazy majority.


Right. In the old days, the release plans were part of the site, generated
from XML, so we needed to announce them so that people would know they were
there. These days, we use the wiki for the release plans, so the
announcement is not strictly necessary (since people see the wiki
notification). Still, an announcement is not a bad idea.

The individual issues are also tracked on the wiki as part of the release
plan now, so it's much easier to keep track of current status. If someone
doesn't like what they see on the wiki page, they'll usually post to the
list about it. I think that fits as "lazy". ;-)

I interpret this to mean that I can [ANNOUNCE] the release plan and
> the intended date, then proceed with tagging the repository and
> creating the test build, as long as -1's do not outnumber +1's.  In
> practice, of course, any -1 is likely to stop the process.
>
> But that's not what has happened for recent releases-- [VOTE]s have
> been called to confirm the release plans themselves, and then again
> for the quality of the proposed releases.


As Niall pointed out, voting on the release plans themselves is a recent
thing, but it's not necessary. For "big" changes, like the first 1.3 test
build, it's not a bad idea, so that we're all sure we're on the same page,
but in general, we've often said that anyone can produce a test build.
Really, the worst that could happen is that it doesn't get a good quality
vote.

I'd suggest that you either 'announce' the release plan, to make sure
everyone is on board, providing a link to the wiki page that includes all
the relevant issues, or just send an 'STP' message (Short Term Plan) stating
your intent to roll a test build.

Am I interpreting the bylaws correctly?  Is there an unwritten rule
> about when you should call a vote on a release plan?


No, I don't think there are unwritten rules. Our current system is
effectively "build first, vote later", because we don't classify the test
build as a release - it's just that, a Test Build.

So, basically, go for it, Wendy. :-) And thanks!

--
Martin Cooper


[1] http://struts.apache.org/bylaws.html
>
> Thanks,
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Bylaws and Releases

[Niall Pemberton <ni...@blueyonder.co.uk>]

Sounds OK to me - the voting on plans seems to have been a recent addition.
I have something almost ready for Bug  38749 - which is in extras. I guess
from this, thats not affected as this is action only?

http://issues.apache.org/bugzilla/show_bug.cgi?id=38749

Niall

----- Original Message ----- 
From: "Wendy Smoak" <ws...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Monday, March 06, 2006 9:28 PM
Subject: Bylaws and Releases


Having volunteered as release manager Struts Action 1.3.1, I'm reading
the instructions. :)

The bylaws [1] say that release plans must be announced on the dev
list and that each issue is decided by lazy majority.

I interpret this to mean that I can [ANNOUNCE] the release plan and
the intended date, then proceed with tagging the repository and
creating the test build, as long as -1's do not outnumber +1's.  In
practice, of course, any -1 is likely to stop the process.

But that's not what has happened for recent releases-- [VOTE]s have
been called to confirm the release plans themselves, and then again
for the quality of the proposed releases.

Am I interpreting the bylaws correctly?  Is there an unwritten rule
about when you should call a vote on a release plan?

[1] http://struts.apache.org/bylaws.html

Thanks,
--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org