My 2 cents.... * Release plans are a good idea IMO and I'd prefer them being a *must* rather than *may* - since it takes a while to get a release out, its a good way of communicating where its at.
* I think test builds such as 1.2.5 should be on the aquiring page, hopefully that will encourage a wider audience to try them out - maybe the first heading on the page should be changed from "Aquiring Struts" to "Released Builds" and then it would be clearer what the status is. * +1 for Tomcat style release. Niall ----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, October 26, 2004 6:28 AM Subject: Re: [VOTE] HTTPD or Tomcat (once more with feeling) [was Adopt ...] On Mon, 25 Oct 2004 21:08:49 -0700, Martin Cooper wrote: > 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, I'm vetoing that product change on the basis that we did not vote on the 1.2.5 build. I think most of us expected there to be a vote after 1.2.5 was rolled and before it was linked from the site. A link on the acquiring page says more about the build than I believe many of us are ready to say. If someone wants to put it back, that's fine. I'm not going to get into a commit war over this. :) > 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. True, we did not discuss whether a release plan is required as part of this thread, which is why I made of point of mentioning that change separately. Since rolling the release involves tagging the repository, I think requiring that a release plan be published in advance is important to be sure "volunteers don't step over each other". We've never had a release without a plan, and the other projects seem to require one implicitly. When I first reduced the release guidelines and bylaws to writing, I used the word "may", and now feel we should say "must" . Again, if someone wants to change the wording back to "may", I won't complain. :) > 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. Neither the website nor the 1.2.5 release plan were in synch with what we were actually doing, and I've done my best, in good faith, to reconcile what we say with what we do. I still think we should use the HTTPD Guidlines out-of-the-box. But when there wasn't support from the other committers, I tried to document the process we followed with 1.2.4, as I understood it. If my understanding is imperfect, then we should make the necessary changes to the guidelines and bylaws to reflect what it is we want to do. It was never my intention to upset anyone. I just wanted to ask whether we wanted to just do what the original Apache team, Apache HTTPD, does, and then correct the website. -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]
