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