: correct me if I'm wrong) to presume that you are saying that it is : alright for the RM to decide what artifacts should be released. So, if : that's not the case, then fine, I agree, but if it is, then no, I don't : think this is the right message to put on the page. And it certainly
I haven't seen anyone even remotely claim that. the The RM most certainly gets to decide what *they* think should be released -- but it is the PMC that gets to decide what *will* be released, and the PMC decides by voting on it. RM is just a label for someone who posts a file online somewhere, signs it, and calls a vote -- they don't have to be a commiter, they don't have to be a PMC member, they don't have to be building off of any specific branch, they don't have to organize their files in any particular way -- all that matters is that they say "here's some stuff, i think we should release it as Apache Foooooo 4.5.6.3.121_a" and it's up to the PMC to say "we're not ging to vote in favor of releasing that, it's just a zip file containing a foo.java file thta doesn't compile because it's just an ascii art picture of a monkey." It's largely meaningless to try and argue that there should be a hard and fast formally voted on process for how we do a release, because a volunteer release manager can't be legally bound to follow that process -- they can just say "screw you guys, this is a pain in the ass i'm going home to do something fun with my time". It's likewise largely meaningless to try and argue that there should be a hard and fast formally voted on set of requirements for what must constitute a release candidate -- because no matter what the PMC might vote on as far as what those rules should be, they would be irrelevant once an actual release vote was called (ie: if PMC feels that all releases need to include a picture of a monkey, you don't need to vote on that as a formal rule - you just need to vote against any release that doesn't include a picture of a monkey) Instead of spending a lot of time arguing over what type of formal process should be involved, and what is mandatory or not, and how to make mandatory things formally mandatory, etc.... it would probably be more productive if folks who have strong opinions about what is important to produce as part of a release just focused on making it easier to do releases that produce those things. For example... Robert feels strongly that releases should always be well tested for many langauges/locales/jvms (+1), so he's been working his ass off to contribute patches that make sure we have an automated way to test these things so we don't have to think hard about them at release time. (++1) If other people feel like releases should always have rock solid support for maven users to consume release artifacts that have accurate poms, then they should contribute patches that make sure we have an automated way to generate/publish those artifacts so we don't have to think hard about them at release time. Likewise: If i feel like releases should always include a picture of a monkey holding the New York times on the day the release is made, then i should contribute a patch that causes the build to generate a picture of a monkey holding the new york times automaticly when the build is run, so we don't have to remember to do it at release time. If any of the various goals conflict (ie: if grant doesn't want to vote in favor of a release because my picture of a monkey doesn't have a pom so it's not useable for maven users; or if robert doesn't want to vote in favor of a release that includes pom's because there are no tests verifying that those poms are usable) then let's argue about those specific, individual, seperate, points in a way that leads towards patches and automation and simplification of process -- Let's try to avoid arguing about formal rules and regulations that just lead to us having formal rules and regulations with no actual implementation or technical solution to make those rules/regulations a reality. -Hoss -- http://lucenerevolution.org/ ... October 7-8, Boston http://bit.ly/stump-hoss ... Stump The Chump! --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
