On 9/10/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > I agree with Frank that, what Ted says, is nice and right and everything, > but it's the theory. The real life shows it's cold shoulder. > > I don't know whether my example fits your question, but at least it fits the > topic of the thread, so it came in handy. > As you might know, or not know, there is an issue with tomcat 5. To make it > short: > You can not use struts (or probably most other jakarta projects) with tomcat > 5. The issue has been submitted. There is a patch available. The bug became > 16 votes (btw. some struts commiters voted too), which is by far most votes > on open tomcat 5 bugs right now. > So far to the community part. The tomcat developers or probably the tomcat > developer in lead, Remy Maucherat, refuses to fix it. > So who really decides? Anyone, but not the community and not the users. (And > please don't think that struts is safe from that)
Looking over the bugzilla ticket, which was posted on Friday, it looks like a healthy discussion to me. Sure, one committer wants the ticket to go away, but he is being overruled. If not by the other committers, certainly by users. Any Tomcat committer can apply that patch. It's not a heirarchy. One comitter does not need to ask another for permission to make a change. In this particular instance, there seems to a problem with the specification. Unfortunately, the last I knew, the scope of the Tomcat project including staying in line with the specification. So, if someone did apply the patch, a PMC member could veto it on that technical ground. If another PMC member seconds the veto, then the patch would have be undone. But, if not for the specification issue, any Tomcat committer could apply that patch. If a PMC member tries to undo another member's change, without a technical justification, the likely result will be loss of his or her Apache account. We've seen that happen before. The ASF board wouldn't rule on a technical issue, but if one project member tries to run the project solo, that member is shown the door. As it stands, in the span of three days, there seems to be available to the public * A patch that users can apply it to their own copy of Tomcat. * A suggestion for a compiled patch that people could just put in their classpath. * A change people can make to the configuation file that solves the problem. If nothing changes by Wednesday, if it were me, I'd submit a patch to the documentation summarizing the issue and pointing to the ticket. I'd also start a thread on Tomcat User to be sure people know about the problem. (Being careful to take that tact: Alert people of the problem, without complaining that no one will apply the patch.) You might also encourage people to send in their request to clarify the specification, as Craig has already done. If the specification is clarified, then the patch is veto-proof. All you need is one Tomcat PMC member who will apply it, and the deed is done. If the issue is not resolved by the time the next release vote comes around, if it were me, I'd vote -1 on the release and encourage everyone involved in the bugzilla ticket and user thread to do the same. The -1s won't be binding, but if the users outvote the committers by a wide margin, people will start to wake up and smell the coffee. (Did someone say coffee?...) -- HTH, Ted. http://www.husted.com/poe/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
