Guys, Before I say anything more, I'd just like to say that it's great to see the discussion taking place here...
>From: Joe Germuska [mailto:[EMAIL PROTECTED]] >Sent: 16 October 2002 00:35 >To: Struts Users Mailing List >Subject: What it will take for a 1.1 release... (was RE: Struts 1.1 >Release) > > >Struts committers are volunteers. That is, they get no compensation >for their work on Struts. Therefore, is it so surprising that their >primary motivation is pride in their work? This means that they are >in no hurry to release too early. I think this is well understood and appreciated by all, and I certainly have no problem with this. I keep beating myself up about having no time to contribute anything - even writing my initial email seemed to take too much time out of my schedule - so the effort and work undertaken by all contributors is admired. >Also, as volunteers, they are likely to devote their time to the most >interesting problems. It appears that few of them find the formal >management of the Struts development process to be a very interesting >problem. This is a bigger open-ended question than the immediate discussion here that I'm sure will have many different perspectives and opinions, but I'll just put it here so that people can offer their thoughts: how far can open source projects based on the work of volunteers, or more specifically (Jakarta/XML/etc) Apache projects go towards following the formalised development process, e.g. as we have to follow for our applications in our strictly controlled environments? What are the practical barriers to this:| e.g. dependence on lack of people willing and/or able to take on this boring stuff. How does this affect take up of such products in large organisations - e.g. off the top of my head, I can think of about 10 projects in my immediate area, leaving aside the many others here, that would I could get to start adopting Struts 1.1 if I could make it available to them. >That said, Struts components like Tiles, Validator, and most >recently, the EL version of the tag libraries were all dreamed up by >someone who saw a need, and they were adopted into Struts because >those people committed their own energy to making something happen. > >Perhaps what Struts needs are some people who are interested in >managing the development process enough that they'll donate time and >energy to it. Or perhaps there will be a company that finds Struts >promising enough that it will endorse some of its staff spending time >and energy while on the job? I think you've identified one of the requirements, but as we've all noted, the reality dictates that this will be very difficult. The latter part is another battle that we're fighting about how to allow our developers to contribute components we write as part of our development of our applications back into open source projects without breaking our policies and raising concerns on intellectual property rights. >I don't know of any official versioning policy besides the vision of >the committers. Perhaps they would concede that it would be OK to >release Struts 1.1 sooner with the understanding that there might be >a Struts 1.1.1 later. Then again, they probably think that anyway, >and they just believe that Struts 1.1 isn't ready yet. It would be very useful to get some clarification of what the current take on this is... >The Release Plan page on the Jakarta site lists the bugs which are >officially targeted for a 1.1 release. However, it's pretty out of >date. Perhaps turning this into a living document would be a good >volunteer opportunity? I think this is a good idea - would be somewhere where people could just go and know that they an clear and accurate picture of the current release status, which they can take back into their discussions. Do others agree, and that this is possible and practical? >It turns out that only two are actually new and open (10537, 7353), >plus one which was reassigned to Commons Validator and switched to an >enhancement. (10584) (details below, since I was taking notes in my >email client...) > > From that, you'd think a 1.1 release was just around the corner!! >However, it's not going to be that easy. My Bugzilla query turns up >39 non-Enhancement open bugs against Struts. Some of these are very >old and may no longer be relevant. (For example, a few refer to the >original File Upload piece, while Struts now uses commons-fileupload.) > >Maybe the first step would be to draft a release plan, even if it had >no specific date on it, if only to track the bugs which were >considered critical fixes for a full release. A question for >committers: is this something you feel you should draft? Or would >you accept a draft from a volunteer? (For the next edition of the >release plan that gets posted on the site, I'd suggesting putting >HTML links straight into bugzilla for each issue, to make it easier >for people to track things.) > >Another significant issue will be in pushing the dependent Commons >packages to full releases, as Struts won't leave beta while it has >dependencies on unreleased code. The beta uses commons-services, >which is still in the Sandbox, and the nightly build also has >dependencies on commons-fileupload and commons-resources which are >both also in the Sandbox. I'm pretty sure all the other dependent >commons jars have had at least one release, although I don't know if >Struts depends on nightly-build-code in any of them. Getting all of >this clearly onto a release plan document on the site will probably >help... I think your above idea about the living document would be a good way to track these such specific issues. >Sorry for the rambling nature of this message, but hopefully it helps >get a few relevant points together... maybe if more email messages >(like yours) focus on "how can Struts 1.1 get released" instead of >"when will Struts 1.1 be released," the pace will pick up a bit. No problem on the rambling - I am often as guilty as anybody else of this. Totally agree on the sentiment about where the focus of this discussion should be - exactly projects should be tackled, i.e. on a task-oriented basis, which complents the release policy. Cheers, Kosh Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
