Gavin, When you sent your message containing the words, "ignore me," I was planning to take you at your word. But since you seem to have continued to continue your campaign of sneer here I guess I'll respond.
1: As it turned out, the vote that started all this concerned 10 issues. I was misled by a JIRA feature. 2: The amount of developer work that goes in is not proportional to the number of JIRAs that come out. 3: The amount of user value that comes out is not proportional to the number of JIRAs that go in. 4: An Apache principle is to encourage people to scratch their itches. This doesn't work if the change you desperately need gets trapped for months waiting for a release. Or, worse, if you get 'held hostage' by demands to fix additional problems that you don't have the expertise to tackle a the price of a release of what you need to fix. All in all, it is very handy that Maven has an automated release process that takes the RM 5 minutes and some PMC members a few more to validate his or her work. This lowers the activation energy. Is there some particular reason why you've chosen to blow a whistle about this particular question? --benson On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly <[email protected]> wrote: > On 20 June 2011 10:48, Gavin McDonald <[email protected]> wrote: >> >> >>> -----Original Message----- >>> From: Lukas Theussl [mailto:[email protected]] On Behalf Of Lukas Theussl >>> Sent: Monday, 20 June 2011 7:25 PM >>> To: Maven Developers List >>> Subject: Re: [VOTE]: release maven-changes-plugin 2.6 >>> >>> >>> >>> Gavin McDonald wrote: >>> > >>> > >>> >> -----Original Message----- >>> >> From: Benson Margulies [mailto:[email protected]] >>> >> Sent: Sunday, 19 June 2011 6:08 AM >>> >> To: Maven Developers List; Maven Project Management Committee List >>> >> Subject: [VOTE]: release maven-changes-plugin 2.6 >>> >> >>> >> Hi, >>> >> >>> >> We solved 3 issues: >>> > >>> > Really? You'd release a product after solving 3 issues? >>> > >>> > Having looked at those 3 issues I believe it can wait for more. >>> >>> Really? And what in your opinion would be the threshold for a release? 5 >>> issues? 16? And if there are no open issues left, do we have to wait for >>> people to find 8 more before we can release it? >> >> Depends on the quality and quantity, whether it fixes a security issue, >> introduces a >> new must have feature, etc. >> >> I would happily vote +1 for a one line security fix. Context is everything. >> >>> >>> Seriously, I think this posting will easily make it on our list of 10 most >>> pointless >>> contributions of the year. >> >> Do not criticise me for making a vote statement. >> >> It was not a contribution, it was a statement regarding the vote, which >> anyone is >> entitled to do. >> >>> When to call a vote for a release is solely the >>> decision of the release manager, and the number of issues is simply >>> irrelevant. >> >> Of course, but am I not entitled to express my vote and supporting >> statement, or >> are all votes expected to be +1 with no comments. > > You are entitled to express your vote and supporting statement, but > the vote is expected to be based on whether the artifacts are > releasable or not. So if for example you identify an issue with the > built software, that could be a -1 or -0. Note that you cannot veto > releases. A -1 can be ignored by the release manager. > >> >> What do you base your vote on exactly? >> > > There are strict criteria for the PMC on which we are supposed to base > our vote on. There are legal requirements that mandate that any > release from Apache must have at least three +1 votes from the PMC for > that Apache project. > > Each voting PMC member is required to ensure that releases meet the following: > > * Every ASF release must contain a source package, which must be > sufficient for a user to build and test the release provided they have > access to the appropriate platform and tools. The source package must > be cryptographically signed by the Release Manager with a detached > signature; and that package together with its signature must be tested > prior to voting +1 for release. Folks who vote +1 for release may > offer their own cryptographic signature to be concatenated with the > detached signature file (at the Release Manager's discretion) prior to > release. > > * Note that the PMC is responsible for all artifacts in their > distribution directory, which is a subdirectory of > www.apache.org/dist/ ; and all artifacts placed in their directory > must be signed by a committer, preferably by a PMC member. It is also > necessary for the PMC to ensure that the source package is sufficient > to build any binary artifacts associated with the release. > > * Every ASF release must comply with ASF licensing policy. This > requirement is of utmost importance and an audit should be performed > before any full release is created. In particular, every artifact > distributed must contain appropriate LICENSE and NOTICE files. More > information can be found in the foundation website and in the release > licensing FAQ. > >> Rolling a new release for a few lines of code that fixes a couple of bugs >> and does not >> introduce any new functionality is overkill IMHO. > > There are a lot of companies out there who will make their employees > jump through hoops if they want to built with a patched version of > build tools that has not come from the build tool's distributor. Thus > to help those people often times it is necessary to roll a release > with the few lines of code as the issue _IS_BLOCKING_TO_THEM_ might be > non-blocking to everyone else. > > We want people to play nice by the community. So please remember that > often times these things are done to support the community. What > people do not like is when the efforts of volunteers are criticized > for not being "enough" work... we are not paid for doing this work, we > do this in our spare time. Sometimes we get abuse from our spouses for > working on this in our spare time... if all we have time to to is roll > out a release with one minor (to you) fix, and no fixes for the issue > you have... well why don't you STEP UP and provide a patch for that > issue, and you know what, a committer might just pick up that patch > and apply the patch and roll a release with that one minor (to them) > fix included. > >> >> But I will stay out of such votes/threads/opinions in the future , do what I >> joined this >> list for, then leave when I'm done. >> > > Actually, don't. Stay and enrich our community > > We welcome people I am disappointed that you have taken criticism of > your critique personally. Please reconsider. We welcome all votes and > opinions (provided they respect the fact that everyone is a volunteer > here). Your critique was not respecting that fact, so your critique > (rightly) got criticism. That does not reflect an opinion on you > personally. > > W.R.T. votes on releases, there is a legal requirement for there to be > votes on releases, and the legal requirement mandates that the PMC > must provide at least 3 +1 votes for each release. We welcome others > to add their votes, but there is no requirement for you to vote. If > there is a vote on a release which you feel is too small of a change > to be worth your (volunteer) time testing... don't test it! > > That is the key feedback mechanism that will prevent people releasing > too often... if the PMC becomes overloaded testing releases from > somebody, well they will take longer and longer to get around to > testing Joe Committer's releases of the Maven LotsOfSmallChanges > Plugin and he will be slowed down in getting his releases out. You > don't need to worry about that (unless you become Joe Committer and > are making many releases with piddling small changes) ;-) > > -Stephen > >> Gav... >> >> >>> >>> -Lukas >>> >>> >>> > >>> > Don’t release for the sake of releasing. >>> > >>> > Gav... >>> > >>> > +-0 non-binding >>> > >>> > >>> >> >>> >> http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 >>> >> >>> >> >>> >> There are plenty of issues left in JIRA: >>> >> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQue >>> >> ry= >>> >> >>> project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE >>> >> SC&mode=hide >>> >> >>> >> Staging repo: >>> >> https://repository.apache.org/content/repositories/maven-024/ >>> >> >>> >> Staging site: >>> >> http://maven.apache.org/plugins/maven-changes-plugin-2.6/ >>> >> >>> >> Guide to testing staged releases: >>> >> http://maven.apache.org/guides/development/guide-testing- >>> releases.htm >>> >> l >>> >> >>> >> Vote open for 72 hours. >>> >> >>> >> [ ] +1 >>> >> [ ] +0 >>> >> [ ] -1 >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [email protected] For >>> >> additional commands, e-mail: [email protected] >>> > >>> > >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: [email protected] For >>> > additional commands, e-mail: [email protected] >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] For additional >>> commands, e-mail: [email protected] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
