Two opposing points af view can be divisive in open source projects, but they need not be. I say branch the code, let both sides run with their ideas. One or both of them will gain a following from both the developer and user communities. This will likely be due to a combination of commumity and technical merits. If both have merit, supporting both is not a bad thing. (I liked being able to choose from the tomcat 3.x/4.x streams, at the time.) More often, one will either fizzle out, or be merged back into the other.
Cheers
ADK
Noel J. Bergman wrote:
It used to be that if you wanted to add a feature to an open source app, you just got the source, added the code and submitted a patch.That is largely the way that James development does work.Now, committers seem to be less receptive to code that does fit with thier idea of "project scope" and "direction" and/or has not been discussed to death on the dev list.The specific concern raised related to an 11th hour decision to fix a long-standing bug. If the same decision had been made a couple of months ago, when everyone was focused on fixing bugs, everyone would have cheered. I don't fault someone for being negative about last minute changes. No one who has ever released commercial software should be favorably disposed towards such changes. I, personally, am negatively predisposed to such changes as a general principle. But in this case, there are enough people waking up to the idea that a fix is in the offing, and asking for it. And given what appears to be the modular nature of the fix (no code changes, a few new classes, and a config.xml change), that it seems warranted to make (and test) the fix.Check out the tomcat list archives for a discussion just prior to the 3.3releasewhere most of the active commiters disagreed with one guy who was keen on continuing active development of the 3.x codebase rather than the 4.x codebase. That was, (IMO) resolved the "right" way - the code wasbranchedand both parties got their way.That specific situation was raised as an example within the past month, and held up in quite the opposite light, including by one of the main participants: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] e.org&msgNo=16161While it is important to retain design cohesion, it is at least as important to allow contributors to "scratch their itch"Agreed. Perhaps we could have pre-branched v3 so that people could continue to contribute code while version 2.1 was prepared for release, but the consensus was that we didn't want to split our focus. Perhaps that was naive, or perhaps something else was an issue. Lastly, let's consider votes and vetoes. Sam Ruby's comment was that "Vetoes are, as a general rule, anti-social behavior and are to be used sparingly. They are to be used to draw attention to stop-ship types of bugs and resolvable design disputes." I think that it is important to keep in mind that a vote and a veto are not the same. The -1 votes I recall were on procedural matters, not technical, and therefore not vetoes. An issue could be raised as to whether or not the file system bug was a stop-ship issue. In which case there would be two perfectly valid and incompatible points of view that would need to be reasonably resolved. One view being the concern over Since Serge wanted to raise the issue of how to structure and deal with technical disputes, I'll follow up by quoting myself from a message I posted to avalon-dev@: "Consider this: why must a justification must be given for a technical veto? Do you suppose that the purpose is simply to provide an excuse for the veto? I submit that it is about providing a basis for reaching a new consensus. Consensus isn't about one person being able to act as a roadblock. It is about focusing attention on critical issues on the belief that the community consensus will be the best solution available at that time." If someone doesn't have James' best interests in mind, that's one thing. But there is no question in my mind that everyone involved in the most recent argument not only has James' best interests genuinely at heart, but has selflessly demonstrated it by deeds. --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
