Hello Fellow Committers,
Ok ... I've at least lessened my ignorance on the two policies by pouring over each of them. Here are my take-aways:
HTTP
- More emphasis put on RM. RM is the end-all be-all decider.
- Builds are (hopefully) tested and then promoted to alpha
- During this process, it is encouraged that the RM coordinate with
those responsible for maintaining the apache.org HTTP instance.
- Testing (alpha -- which makes 100% sense ... it's in-house and pre-
publicly available) ensues for 48-72 hours.
- If the alpha passes the stress-test, it "becomes" 'the' release.
Tomcat
- More emphasis put on the group.
- Committers must authorize the release
- In other words, there will be a vote before something is labeled
as a "beta" or GA
- PMC members then authorize distribution of the release.A "release" is a distribution sanctioned by Apache. A build is ... just a build :-)
Overall, not to step on any toes, but nomenclature and all, as well as the process involved ... it "feels" to me as though we've been working under the Tomcat rules the whole time I've been aware of the project. I can't speak for the time I was absent, of course, but it makes sense that we would have been guided by the Tomcat project too. They're in our "community" and have, in many ways, paved the way for "Jakarta things".
I like the fact that the Tomcat strategy de-empasizes any individual and puts emphasis on the group decision. I see this as being protective of our reputation -- and that's pretty important. OpenSource gains momentum all the time, but there's still some doubtful people out there. Such people are easily swayed by instances of things that failed. I'd hate for our process to enable us to be that instance of failure. As such, I feel it would be behove us to remain under the guidelines set forth under the Tomcat policies.
Using the Tomcat model ensures that nothing is denoted a sanctioned release without a majority (+3 with no -1s) agreement. Yes, you could have one ... <throat:clear/> ... very difficult to satisfy person who could hold things up, but, in the end, it's all about QA.
With all due respect Ted, and you're due a lot in my eyes - I've learned tons from you during my involvement in the project - I don't see how you can say that we adhere to both ideas. One clearly (to me) empasizes an individual (the RM, but still one person) over the group. The other leans toward group consensus. I'm in favor of emphasizing the group and not any one person.
It's not just Struts' reputation we're protecting. It's the reputation of Jakarta, Apache, and even OpenSource.
+1 for Tomcat style release.
Respectfully,
Eddie Bush
----- Original Message ----- From: "Martin Cooper" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 25, 2004 11:08 PM
Subject: Re: [VOTE] HTTPD or Tomcat (once more with feeling) [was Adopt ...]
On Sat, 23 Oct 2004 06:47:34 -0400, Ted Husted <[EMAIL PROTECTED]> wrote:I don't agree that it makes any practical difference whether we use Tomcat or HTTPD. Most people won't even notice the difference. (I didn't at first.) I'd still prefer going with HTTPD "out of the box" for the sake of standardization.
My own feelings aside, I updated the website to coincide with what we discussed here.
I'm sorry, but I don't believe your changes reflect the discussions here at all. We did not discuss removing the development build availability from the 'aquiring' page, and did not discuss the re-introduction of the requirement for a release plan. Those are both points I happen to disagree with. I don't think either was a necessary change from where we were already.
However, I'm so totally pissed off with this discussion that I'm not going to bother trying to push for what I believe is the right way to do this, and I'll let Ted define the process we use, even if I consider that to be the wrong way. If everyone else is happy with that, then so be it.
-- Martin Cooper
Most of the issues raised in this thread should be resolved as part of the release plan, rather than after the distribution (or proposed release) has been rolled. If posting a release plan is *required* before tagging the repository, then a lot of these concerns go away.
If a release plan is not enough to save us from "committers gone wild", then we have problems that a "test build" phase won't fix. :)
Accordingly, I strengthened the need for a formal plan in the Release Guidelines and Bylaws, and I also tweaked the Release Plan checklist for 1.2.5 to clarify the terminology and sequence of events. The changes are in the repository and posted to the site, subject to lazy consensus.
-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]
--- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0443-3, 10/22/2004 Tested on: 10/26/2004 12:21:31 AM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
