maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gavin McDonald" <ga...@16degrees.com.au>
Subject RE: [VOTE]: release maven-changes-plugin 2.6
Date Mon, 20 Jun 2011 11:53:46 GMT


> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Monday, 20 June 2011 9:00 PM
> To: Maven Developers List
> Cc: gavin@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.connolly@gmail.com> wrote:
> > On 20 June 2011 10:48, Gavin McDonald <gavin@16degrees.com.au>
> wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: Lukas Theussl [mailto:ltheussl@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:bimargulies@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-unsubscribe@maven.apache.org For
> >>> >> additional commands, e-mail: dev-help@maven.apache.org
> >>> >
> >>> >
> >>> >
> >>> > ------------------------------------------------------------------
> >>> > --- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> >>> > additional commands, e-mail: dev-help@maven.apache.org
> >>> >
> >>>
> >>> --------------------------------------------------------------------
> >>> - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> >>> additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> >> additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
> commands, e-mail: dev-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message