Jon Stevens wrote: > > I'm not interested in bringing new projects into Jakarta when we are as > fucked up as we are today. It is utter anarchy here and I don't think that > is good. People can't even follow the rules we have *defined*. > > People, it isn't about code standards, that is just the symptom of the > larger problem.
People not following the coding standards clearly is a bug. The correct fix is likely to be to reword the guidelines to make it clear that they are, well, guidelines. And perhaps to add working to encourage subprojects to not only define standards, but also to explore viable ways to enforce them. Who knows, if somebody comes up with such a scheme (and I already outlined what type of mechanism I would find acceptable), then perhaps we would consider adopting it project wide. OK, so cast in product terms and continuing the bug analogy. Given the proposed fix above, I would not consider it a "stop ship issue". In terms of where I have chosen to invest my Apache related hours, I've made it clear what types of issues I view as affecting the communities health. So we've established that we've got a bug. What should we do about it? 1) Perhaps we need to use the bug tracking system for PMC issues. That would be a welcome improvement. Anybody care to take this one? 2) Related to POI. As long as they know the current state of Jakarta and can make an informed decision, and meet all the criteria described in http://jakarta.apache.org/site/newproject.html, then they have my +1. After all, what good is it to have published criteria which omits important "details" like "Jon will block if he feels that Jakarta is fucked up today"? ;-) Oh, and Stefano's stewardship more than sufficiently meets that particular criteria in my book. 3) Related to bugs in general. They happen. Given that this is an all volunteer organization, perhaps more people should read http://jakarta.apache.org/site/understandingopensource.html . My feeling is the sentiments that are expressed there apply equally well to the organization as a whole as they do to the status of any particular code base. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
