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.
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. 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? Of course, all of this is said best on the Struts site itself at this link: <http://jakarta.apache.org/struts/helping.html#release_help> Anyway, here are some reactions to specifics in your email: >Would it be possible to change the versioning policy so that more >non-beta dot releases are made possible, since many components are >known to have no issues? 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. >So I would be interested in hearing any suggestions about how we >could resolve the need for us to have a better understanding of how >close we are to a final release of any given version, e.g. clearly >listing the issues that are preventing a release being deemed as 1.1 >quality on the website? 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? 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... 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. Joe ------------- Custom Tags 1586 The <html:form> tag generates incorrect focus javascript for radio buttons. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1586 status "RESOLVED/LATER" ------------- Documentation 10537 [:TODO:] sections (18) http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10537 status: "NEW" notes made in this issue in the last few days show that it's under active work. ------------- Example Webapps 10955 Error running struts-blank applicaiton under JRun 3.1 Validator Framework http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10955 status "RESOLVED/FIXED" ------------- Example Webapps 7353 Validator JavaScript Select Error http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7353 status "NEW" recently re-assigned to "the list", which means it's looking for someone to take it -- maybe you? ------------- Example Webapps 10191 Validator range checking bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10191 status "RESOLVED/FIXED" ------------- Example Webapps 10348 Validator is not available under sub-application http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10348 status "RESOLVED/FIXED" ------------- Example Webapps 10349 Validator: date validation does not allow blank input? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10349 status "RESOLVED/DUPLICATE" ------------- Example Webapps 10432 DynaValidatorActionForm does not validate data http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10432 status "RESOLVED/WORKSFORME" ------------- Example Webapps 10584 Not all validation files are read in Validation PlugIn http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10584 Reassigned to Commons Validator, and priority set to "Enhancement" -- -- * Joe Germuska { [EMAIL PROTECTED] } "It's pitiful, sometimes, if they've got it bad. Their eyes get glazed, they go white, their hands tremble.... As I watch them I often feel that a dope peddler is a gentleman compared with the man who sells records." --Sam Goody, 1956 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
