> -----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
