Gavin, Since I seem to have misread your tone, I apologize.
--benson On Mon, Jun 20, 2011 at 7:53 AM, Gavin McDonald <ga...@16degrees.com.au> wrote: > > >> -----Original Message----- >> From: Benson Margulies [mailto:bimargul...@gmail.com] >> Sent: Monday, 20 June 2011 9:00 PM >> To: Maven Developers List >> Cc: ga...@16degrees.com.au >> Subject: Re: [VOTE]: release maven-changes-plugin 2.6 >> >> 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. > > Sure, understandable, I too followed the link you gave as part of the vote. > >> >> 2: The amount of developer work that goes in is not proportional to the >> number of JIRAs that come out. > > I'm not sure I mentioned anything about this. > >> >> 3: The amount of user value that comes out is not proportional to the >> number of JIRAs that go in. > > I'm not sure I mentioned anything about this. > >> >> 4: An Apache principle is to encourage people to scratch their itches. > > After 6 years at Apache I get that. > > >> 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. > > I don’t get how this is relevant to my voting on the specifics of a few lines > of > changed code. I was basing this on the link you gave to the 3 Jira Issues. We > now know it was 10 issues. > >> >> 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. > > That’s good, someone else in this thread earlier was making out it’s a really > hard process > and so therefore why would anyone do it for the sake of it. Glad to be > corrected > there. > >> >> Is there some particular reason why you've chosen to blow a whistle about >> this particular question? > > This was no vendetta, no campaign of sneer, nothing against yourself, I know > what > you do it Apache and where, you work hard, do not take this as anything other > than > querying why would anyone do a release based on 3 issues and a few lines of > code. > > It was just that , no more, no less, I do not get all the hostility that has > come from such > a query, than one is entitled to do. > > Please, let s drop this, I have now unsubscribed from the list. > > Gav... > >> >> --benson >> >> >> On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly >> <stephen.alan.conno...@gmail.com> wrote: >> > On 20 June 2011 10:48, Gavin McDonald <ga...@16degrees.com.au> >> wrote: >> >> >> >> >> >>> -----Original Message----- >> >>> From: Lukas Theussl [mailto:ltheu...@gmail.com] 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:bimargul...@gmail.com] >> >>> >> 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&jq >> >>> >> lQue >> >>> >> 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: dev-unsubscr...@maven.apache.org For >> >>> >> additional commands, e-mail: dev-h...@maven.apache.org >> >>> > >> >>> > >> >>> > >> >>> > ------------------------------------------------------------------ >> >>> > --- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For >> >>> > additional commands, e-mail: dev-h...@maven.apache.org >> >>> > >> >>> >> >>> -------------------------------------------------------------------- >> >>> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For >> >>> additional commands, e-mail: dev-h...@maven.apache.org >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For >> >> additional commands, e-mail: dev-h...@maven.apache.org >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For >> > additional commands, e-mail: dev-h...@maven.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional >> commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
