And, AFAIK, what we are doing is compatible with what Tomcat is doing, and Tomcat is also still under the Jakarta umbrella.
Of course, until we have our own PMC, we do need to give the Jakarta PMC notice of the release, so as to make it a legal release of the Foundation. But, we have already documented that in our own Release Guidelines document. (Traditionally, what is published at the top-level of Jakarta were guidelines that products could observe until they documented their own guidelines, which is what we have been doing.)
Whether or not we should have our own PMC, which is to say petition to become a top-level Apache project, is a topic that I would like to discuss once 1.2.0 is released. But first things first :)
-Ted.
Martin Cooper wrote:
The issue isn't so much with voting on the relesae plan, but voting on the release itself. As you say, the HTTPD rules say that anyone can create a release. We're not HTTPD, though, and the Jakarta rules are different. As long as we're part of Jakarta, we need to abide by the Jakarta rules.
Under "Decision Making", in the section on "Release Testing", is the following statement:
"Majority approval is required before the release can be made." http://jakarta.apache.org/site/decisions.html
So, we do need to vote on each and every release.
-- Martin Cooper
On Tue, 16 Dec 2003, Ted Husted wrote:
With this proposal, I took a middle ground. The initial minor release (x.x.0) in a series called for a vote on a plan, but a plan would be optional for additional releases in the same series (1.2.1, 1.2.2, ...). So, we wouldn't have to vote on a plan again until we get to 1.3.0 or 2.0.0.
The rationale is that starting a new series (1.2.0 versus 1.1.0) is a decision upon which we should have a formal consensus. After that, issuing additional point releases in the same series can be "business as usual" .
Of course, this is just a vote on the plan. Once we roll the release, there would be another vote on whether to take that specific entity from Alpha to Beta and/or General Availability. (Though, personally, I prefer the more common "stable" designation to GA.)
Of course, as the HTTPD guidelines point out, under the Apache License, anyone can distribute a release of our codebase. It's just a matter of whether it can be called "Struts" or not. :)
-Ted,
Martin Cooper wrote:
+1
I've added myself as an RM, since I'll be available to help. I can take on the tag, roll, sign and announce part, if you like.
One thing I'd like to point out, because it came up in Commons, is that the HTTPD process and the Jakarta process are not 100% compatible. In particular, the Jakarta rules require a vote, while the HTTPD rules do not. I suspect that this vote may be sufficient, but I'll check when I get a chance.
-- Martin Cooper
On Tue, 16 Dec 2003, Ted Husted wrote:
I've amended the date on the (now venerable) 1.2.0 release plan for this weekend.
http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
I believe the release notes are in good shape now. I already marched through most of the stale 1.0/1.1 tickets, and can mop up the rest in short order. I imagine there will be a few patches that we can apply, but I've carved out some time to work on such.
Note that I've left room in the release plan for the idea of multiple managers. If someone were up for sheparding the tests, especially the example application testing, I'd welcome the help. Someone else could also sign up for the final tag, roll, and announce part of the job. Of course, if everyone is busy, I'll be happy to muddle through on my own. :)
Since this is a x.0 release, the plan calls for a majority vote.
Here's my +1
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
