Gavin McDonald 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 issues seems like doing a days work ..."

quoted from http://www.mail-archive.com/dev@maven.apache.org/msg88624.html



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.

"... Don’t release for the sake of releasing... "

quoted from http://www.mail-archive.com/dev@maven.apache.org/msg88586.html

-Lukas




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

Reply via email to