You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2011/06/18 22:07:58 UTC
[VOTE]: release maven-changes-plugin 2.6
Hi,
We solved 3 issues:
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&jqlQuery=project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DESC&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.html
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
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Benson Margulies <bi...@gmail.com>.
Well, that explains that. 2.6 it is, and new vote coming soon.
On Sun, Jun 19, 2011 at 8:02 AM, Dennis Lundberg <de...@apache.org> wrote:
> On 2011-06-19 13:39, Benson Margulies wrote:
>> Kristian,
>>
>> How are you seeing 10?
>
> In the release notes:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17375&styleName=Text&projectId=11212
>
> In JIRA 4 the default layout changed so that it shows some sort of
> summary, which I don't understand the need for at all. It shows the 3
> most recently updated issues:
> http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375
>
> If you want to see *all* issues for that version (who doesn't?) you need
> to click on the "Issues" tab on the left. Not very user friendly is you
> ask me...
>
>
>>
>> --benson
>>
>>
>> On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold
>> <kr...@gmail.com> wrote:
>>> Dont know if we're looking at the same jira; I see 10 issues being
>>> resolved.
>>>
>>> +1 binding
>>>
>>> Given the amount of *work* staging a release is, I hardly doubt anyone
>>> does a release they don't think is worth it.
>>>
>>> Kristian
>>>
>>>
>>> sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald:
>>>>
>>>>> -----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.
>>>>
>>>> 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&jqlQuery=
>>>>> 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.html
>>>>>
>>>>> 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
>>
>>
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Dennis Lundberg <de...@apache.org>.
On 2011-06-19 13:39, Benson Margulies wrote:
> Kristian,
>
> How are you seeing 10?
In the release notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17375&styleName=Text&projectId=11212
In JIRA 4 the default layout changed so that it shows some sort of
summary, which I don't understand the need for at all. It shows the 3
most recently updated issues:
http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375
If you want to see *all* issues for that version (who doesn't?) you need
to click on the "Issues" tab on the left. Not very user friendly is you
ask me...
>
> --benson
>
>
> On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold
> <kr...@gmail.com> wrote:
>> Dont know if we're looking at the same jira; I see 10 issues being
>> resolved.
>>
>> +1 binding
>>
>> Given the amount of *work* staging a release is, I hardly doubt anyone
>> does a release they don't think is worth it.
>>
>> Kristian
>>
>>
>> sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald:
>>>
>>>> -----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.
>>>
>>> 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&jqlQuery=
>>>> 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.html
>>>>
>>>> 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
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Kristian Rosenvold <kr...@gmail.com>.
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11212&version=17375
??
Den 19. juni 2011 kl. 13:40 skrev Benson Margulies <bi...@gmail.com>:
> Kristian,
>
> How are you seeing 10?
>
> --benson
>
>
> On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold
> <kr...@gmail.com> wrote:
>> Dont know if we're looking at the same jira; I see 10 issues being
>> resolved.
>>
>> +1 binding
>>
>> Given the amount of *work* staging a release is, I hardly doubt anyone
>> does a release they don't think is worth it.
>>
>> Kristian
>>
>>
>> sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald:
>>>
>>>> -----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.
>>>
>>> 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&jqlQuery=
>>>> 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.html
>>>>
>>>> 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
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Benson Margulies <bi...@gmail.com>.
Kristian,
How are you seeing 10?
--benson
On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold
<kr...@gmail.com> wrote:
> Dont know if we're looking at the same jira; I see 10 issues being
> resolved.
>
> +1 binding
>
> Given the amount of *work* staging a release is, I hardly doubt anyone
> does a release they don't think is worth it.
>
> Kristian
>
>
> sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald:
>>
>> > -----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.
>>
>> 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&jqlQuery=
>> > 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.html
>> >
>> > 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
RE: [VOTE]: release maven-changes-plugin 2.6
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Kristian Rosenvold [mailto:kristian.rosenvold@gmail.com]
> Sent: Sunday, 19 June 2011 7:50 PM
> To: 'Maven Developers List'
> Subject: RE: [VOTE]: release maven-changes-plugin 2.6
>
> Dont know if we're looking at the same jira; I see 10 issues being resolved.
Probably not, I'm looking at the link that Benson gave:
http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375
and combining that with the words:
"> > > We solved 3 issues:"
I think you are looking in the wrong place.
>
> +1 binding
>
> Given the amount of *work* staging a release is, I hardly doubt anyone does
> a release they don't think is worth it.
Compared to some other projects, not much work at all.
Gav...
>
> Kristian
>
>
> sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald:
> >
> > > -----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.
> >
> > 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&jqlQu
> > > ery=
> > >
> 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.ht
> > > ml
> > >
> > > 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
RE: [VOTE]: release maven-changes-plugin 2.6
Posted by Kristian Rosenvold <kr...@gmail.com>.
Dont know if we're looking at the same jira; I see 10 issues being
resolved.
+1 binding
Given the amount of *work* staging a release is, I hardly doubt anyone
does a release they don't think is worth it.
Kristian
sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald:
>
> > -----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.
>
> 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&jqlQuery=
> > 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.html
> >
> > 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
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Benson Margulies <bi...@gmail.com>.
Please make a new thread.
On Mon, Jun 20, 2011 at 5:51 PM, Mark Derricutt <ma...@talios.com> wrote:
> (Other) Mark,
>
> I'm not sure I see the connection here? Lukas had made comment that making
> one release would trigger cascading releases, which I assume is because
> downstream plugins have fixed version number dependencies.
>
> However if those dependencies were [1.0,2.0) then they would use the most
> recent automatically without having to rerelease everything.
>
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>
> On Tue, Jun 21, 2011 at 8:39 AM, Mark Struberg <st...@yahoo.de> wrote:
>
>> Mark,
>>
>> maybe this is not so obvious, but Maven internally has ClassLoader
>> isolation between plugins. This is comparable to a servlet container where 1
>> webapp only can see its own classes. This way it is no problem that there
>> are more versions of a plugin (or any other dependency) being used in the
>> same maven build.
>>
>> LieGrue,
>> strub
>>
>> --- On Mon, 6/20/11, Mark Derricutt <ma...@talios.com> wrote:
>>
>> > From: Mark Derricutt <ma...@talios.com>
>> > Subject: Re: [VOTE]: release maven-changes-plugin 2.6
>> > To: "Maven Developers List" <de...@maven.apache.org>
>> > Date: Monday, June 20, 2011, 8:27 PM
>> > Wow - that seems like a hell of a lot
>> > of releases having to be made...
>> >
>> > This post is probably drifting off topic but the thing that
>> > strikes me here
>> > is that this is the exact reason why maven supports version
>> > ranges - so that
>> > you don't have to make a plethora of rolling releases just
>> > because one
>> > change was made downstream.
>> >
>> > It's no wonder a lot of version range bugs in maven never
>> > get fixed if none
>> > of the plugins or maven itself actually uses them. Of
>> > course this only
>> > solves the problem where an upstream release contains
>> > non-breaking changes
>> > for its downstream users which hopefully, for bug fixes
>> > would be more often
>> > than not.
>> >
>> > Locking down versions is good for third party dependencies,
>> > but I'm very
>> > much of the mind that ranges should be used for sibings,
>> > would certainly
>> > solve the problem of transitive release blowouts.
>> >
>> >
>> > --
>> > "Great artists are extremely selfish and arrogant things"
>> > — Steven Wilson,
>> > Porcupine Tree
>> >
>> >
>> > On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold <
>> > kristian.rosenvold@gmail.com>
>> > wrote:
>> >
>> > >
>> > >
>> > > Den 19.06.2011 23:08, skrev Gavin McDonald:
>> > >
>> > >
>> > >> I would be happy with weeks to be honest. Then
>> > again I have been used to
>> > >> being around
>> > >> slower projects that have released only every 2 or
>> > 3 years once 1 or 2
>> > >> hundred issues have
>> > >> been gathered into a release. And the release
>> > process itself takes weeks
>> > >> of work to
>> > >> achieve.
>> > >>
>> > >> Therefore ignore me, 3 issues seems like doing a
>> > days work, then release,
>> > >> then another days
>> > >> work, then release etc ...
>> > >>
>> > >>
>> > > Given a very quick count, the apache maven project
>> > contains something like
>> > > 90 individually deployable and separately votable
>> > artifacts. Our users
>> > > upgrade these components individually according to
>> > need. Each component is
>> > > individually tested and voted for; maven is not a
>> > monolithic application and
>> > > should not be released as one.
>> > >
>> > > The downside of this componentization is that
>> > sometimes fixing a single
>> > > issue leads to the redeployment of multiple artifacts,
>> > at the moment I'm
>> > > working on 1 issue that will require the
>> > > redeployment of 8 different artifacts (6 votes at
>> > apache, 2 elsewhere)
>> > > before it's closed in its full extent. Most likely
>> > I'll have votes for 2 of
>> > > these "soon" and I'll just let the remaining 4 roll
>> > out
>> > > together with releases planned by others. But in this
>> > context I simply
>> > > refuse to consider if a single release vote is too
>> > large or too small.
>> > >
>> > > From an agile perspective there's potential to getting
>> > a lot more issues
>> > > fixed with a single year than the kind of project you
>> > mention. I have no
>> > > specific stats but I assume we fix at least a thousand
>> > issues every year.
>> > >
>> > > Some of our projects have sufficiently good automated
>> > test coverage that I
>> > > suspect we could allow incremental .1 releases to go
>> > without a vote
>> > > entirely. I'm not sure if this is something we're even
>> > allowed to consider
>> > > ;) (Surefire would probably qualify, assuming we did
>> > some kind of formalized
>> > > "continious production" kind of review)
>> > >
>> > > I think ideally we should release every top-level
>> > component every 6 weeks
>> > > or so. But that means we'd have 1-3 votes every day
>> > ;)
>> > >
>> > >
>> > > Kristian
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > ------------------------------**------------------------------**---------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
>> 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
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Mark Derricutt <ma...@talios.com>.
(Other) Mark,
I'm not sure I see the connection here? Lukas had made comment that making
one release would trigger cascading releases, which I assume is because
downstream plugins have fixed version number dependencies.
However if those dependencies were [1.0,2.0) then they would use the most
recent automatically without having to rerelease everything.
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On Tue, Jun 21, 2011 at 8:39 AM, Mark Struberg <st...@yahoo.de> wrote:
> Mark,
>
> maybe this is not so obvious, but Maven internally has ClassLoader
> isolation between plugins. This is comparable to a servlet container where 1
> webapp only can see its own classes. This way it is no problem that there
> are more versions of a plugin (or any other dependency) being used in the
> same maven build.
>
> LieGrue,
> strub
>
> --- On Mon, 6/20/11, Mark Derricutt <ma...@talios.com> wrote:
>
> > From: Mark Derricutt <ma...@talios.com>
> > Subject: Re: [VOTE]: release maven-changes-plugin 2.6
> > To: "Maven Developers List" <de...@maven.apache.org>
> > Date: Monday, June 20, 2011, 8:27 PM
> > Wow - that seems like a hell of a lot
> > of releases having to be made...
> >
> > This post is probably drifting off topic but the thing that
> > strikes me here
> > is that this is the exact reason why maven supports version
> > ranges - so that
> > you don't have to make a plethora of rolling releases just
> > because one
> > change was made downstream.
> >
> > It's no wonder a lot of version range bugs in maven never
> > get fixed if none
> > of the plugins or maven itself actually uses them. Of
> > course this only
> > solves the problem where an upstream release contains
> > non-breaking changes
> > for its downstream users which hopefully, for bug fixes
> > would be more often
> > than not.
> >
> > Locking down versions is good for third party dependencies,
> > but I'm very
> > much of the mind that ranges should be used for sibings,
> > would certainly
> > solve the problem of transitive release blowouts.
> >
> >
> > --
> > "Great artists are extremely selfish and arrogant things"
> > — Steven Wilson,
> > Porcupine Tree
> >
> >
> > On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold <
> > kristian.rosenvold@gmail.com>
> > wrote:
> >
> > >
> > >
> > > Den 19.06.2011 23:08, skrev Gavin McDonald:
> > >
> > >
> > >> I would be happy with weeks to be honest. Then
> > again I have been used to
> > >> being around
> > >> slower projects that have released only every 2 or
> > 3 years once 1 or 2
> > >> hundred issues have
> > >> been gathered into a release. And the release
> > process itself takes weeks
> > >> of work to
> > >> achieve.
> > >>
> > >> Therefore ignore me, 3 issues seems like doing a
> > days work, then release,
> > >> then another days
> > >> work, then release etc ...
> > >>
> > >>
> > > Given a very quick count, the apache maven project
> > contains something like
> > > 90 individually deployable and separately votable
> > artifacts. Our users
> > > upgrade these components individually according to
> > need. Each component is
> > > individually tested and voted for; maven is not a
> > monolithic application and
> > > should not be released as one.
> > >
> > > The downside of this componentization is that
> > sometimes fixing a single
> > > issue leads to the redeployment of multiple artifacts,
> > at the moment I'm
> > > working on 1 issue that will require the
> > > redeployment of 8 different artifacts (6 votes at
> > apache, 2 elsewhere)
> > > before it's closed in its full extent. Most likely
> > I'll have votes for 2 of
> > > these "soon" and I'll just let the remaining 4 roll
> > out
> > > together with releases planned by others. But in this
> > context I simply
> > > refuse to consider if a single release vote is too
> > large or too small.
> > >
> > > From an agile perspective there's potential to getting
> > a lot more issues
> > > fixed with a single year than the kind of project you
> > mention. I have no
> > > specific stats but I assume we fix at least a thousand
> > issues every year.
> > >
> > > Some of our projects have sufficiently good automated
> > test coverage that I
> > > suspect we could allow incremental .1 releases to go
> > without a vote
> > > entirely. I'm not sure if this is something we're even
> > allowed to consider
> > > ;) (Surefire would probably qualify, assuming we did
> > some kind of formalized
> > > "continious production" kind of review)
> > >
> > > I think ideally we should release every top-level
> > component every 6 weeks
> > > or so. But that means we'd have 1-3 votes every day
> > ;)
> > >
> > >
> > > Kristian
> > >
> > >
> > >
> > >
> > >
> > >
> > ------------------------------**------------------------------**---------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
> 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
>
>
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Mark Struberg <st...@yahoo.de>.
Mark,
maybe this is not so obvious, but Maven internally has ClassLoader isolation between plugins. This is comparable to a servlet container where 1 webapp only can see its own classes. This way it is no problem that there are more versions of a plugin (or any other dependency) being used in the same maven build.
LieGrue,
strub
--- On Mon, 6/20/11, Mark Derricutt <ma...@talios.com> wrote:
> From: Mark Derricutt <ma...@talios.com>
> Subject: Re: [VOTE]: release maven-changes-plugin 2.6
> To: "Maven Developers List" <de...@maven.apache.org>
> Date: Monday, June 20, 2011, 8:27 PM
> Wow - that seems like a hell of a lot
> of releases having to be made...
>
> This post is probably drifting off topic but the thing that
> strikes me here
> is that this is the exact reason why maven supports version
> ranges - so that
> you don't have to make a plethora of rolling releases just
> because one
> change was made downstream.
>
> It's no wonder a lot of version range bugs in maven never
> get fixed if none
> of the plugins or maven itself actually uses them. Of
> course this only
> solves the problem where an upstream release contains
> non-breaking changes
> for its downstream users which hopefully, for bug fixes
> would be more often
> than not.
>
> Locking down versions is good for third party dependencies,
> but I'm very
> much of the mind that ranges should be used for sibings,
> would certainly
> solve the problem of transitive release blowouts.
>
>
> --
> "Great artists are extremely selfish and arrogant things"
> — Steven Wilson,
> Porcupine Tree
>
>
> On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold <
> kristian.rosenvold@gmail.com>
> wrote:
>
> >
> >
> > Den 19.06.2011 23:08, skrev Gavin McDonald:
> >
> >
> >> I would be happy with weeks to be honest. Then
> again I have been used to
> >> being around
> >> slower projects that have released only every 2 or
> 3 years once 1 or 2
> >> hundred issues have
> >> been gathered into a release. And the release
> process itself takes weeks
> >> of work to
> >> achieve.
> >>
> >> Therefore ignore me, 3 issues seems like doing a
> days work, then release,
> >> then another days
> >> work, then release etc ...
> >>
> >>
> > Given a very quick count, the apache maven project
> contains something like
> > 90 individually deployable and separately votable
> artifacts. Our users
> > upgrade these components individually according to
> need. Each component is
> > individually tested and voted for; maven is not a
> monolithic application and
> > should not be released as one.
> >
> > The downside of this componentization is that
> sometimes fixing a single
> > issue leads to the redeployment of multiple artifacts,
> at the moment I'm
> > working on 1 issue that will require the
> > redeployment of 8 different artifacts (6 votes at
> apache, 2 elsewhere)
> > before it's closed in its full extent. Most likely
> I'll have votes for 2 of
> > these "soon" and I'll just let the remaining 4 roll
> out
> > together with releases planned by others. But in this
> context I simply
> > refuse to consider if a single release vote is too
> large or too small.
> >
> > From an agile perspective there's potential to getting
> a lot more issues
> > fixed with a single year than the kind of project you
> mention. I have no
> > specific stats but I assume we fix at least a thousand
> issues every year.
> >
> > Some of our projects have sufficiently good automated
> test coverage that I
> > suspect we could allow incremental .1 releases to go
> without a vote
> > entirely. I'm not sure if this is something we're even
> allowed to consider
> > ;) (Surefire would probably qualify, assuming we did
> some kind of formalized
> > "continious production" kind of review)
> >
> > I think ideally we should release every top-level
> component every 6 weeks
> > or so. But that means we'd have 1-3 votes every day
> ;)
> >
> >
> > Kristian
> >
> >
> >
> >
> >
> >
> ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@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
Re: ranges and cascading releases was: [VOTE]: release
maven-changes-plugin 2.6
Posted by Benson Margulies <bi...@gmail.com>.
I'm with Kristian, as if he needs any help here.
We aren't anywhere near where we'd have to be to feel confident that a
release of some component was guaranteed regression-free in all
obscure cases.
One small thought: if people would mark their votes 'binding' or
'nonbinding', it would reduce the effort of collating them. The easier
the process is, the more releases we can make.
I'm always happy to rm.
On Tue, Jun 21, 2011 at 2:57 AM, Kristian Rosenvold
<kr...@gmail.com> wrote:
> Technically I'd get away with updating 2-3 artifacts, but I'd end up writing
> a cookbook on how to add a crapload of dependencies to the plugins in
> question and answering on the mailing list and irc, and in the end we'd have
> a ton of poms lying around with 3 overridden dependencies in 4-5 plugins. So
> as as service to our end users I think the fair thing is to release new
> versions. Now given that we manage to maintain an "average" release schedule
> of 4-8 weeks, I would probably just ignore releasing the plugin, but
> currently I think our release schedules are driven by itches like mine. So I
> suppose we *could* solve this by just assigning regular releases to
> committers. Personally I don't /mind/ taking responsibility for releasing
> 2-3 plugins every 6-8 weeks if I knew someone else did the others.
>
> I think version ranges for plugins are fairly dangerous because you'll be
> removing the determinism in the build. Even though you lock down plugin
> versions, you risk getting a new version of maven-shared-foobar any day. I
> just need introduce *1* platform specific bug in maven-shared-foobar to
> paralyze the entire community of "windows" users. I've seen this happen in
> other projects that (for instance) have *no* committers working on windows
> (yes, it's becoming fairly commonplace).
>
> Kristian
>
>
>
> Den 21.06.2011 02:38, skrev Brett Porter:
>>
>> Kristian can describe in more detail what he's working on, but not all
>> changes take 8 artifact changes. In this case I think it's both that it's
>> something that affects multiple things (rather than dependencies), and also
>> a couple of things that have been broken down to one too separate many
>> artifacts (like plexus-compiler, which I think is only ever used in the
>> compiler plugin). Those sorts of exercises should actually help us
>> understand if the right type of modularity has been applied.
>>
>> - Brett
>>
>> On 21/06/2011, at 6:27 AM, Mark Derricutt wrote:
>>
>>> Wow - that seems like a hell of a lot of releases having to be made...
>>>
>>> This post is probably drifting off topic but the thing that strikes me
>>> here
>>> is that this is the exact reason why maven supports version ranges - so
>>> that
>>> you don't have to make a plethora of rolling releases just because one
>>> change was made downstream.
>>>
>>> It's no wonder a lot of version range bugs in maven never get fixed if
>>> none
>>> of the plugins or maven itself actually uses them. Of course this only
>>> solves the problem where an upstream release contains non-breaking
>>> changes
>>> for its downstream users which hopefully, for bug fixes would be more
>>> often
>>> than not.
>>>
>>> Locking down versions is good for third party dependencies, but I'm very
>>> much of the mind that ranges should be used for sibings, would certainly
>>> solve the problem of transitive release blowouts.
>>>
>>>
>>> --
>>> "Great artists are extremely selfish and arrogant things" — Steven
>>> Wilson,
>>> Porcupine Tree
>>>
>>>
>>> On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold<
>>> kristian.rosenvold@gmail.com> wrote:
>>>
>>>>
>>>> Den 19.06.2011 23:08, skrev Gavin McDonald:
>>>>
>>>>
>>>>> I would be happy with weeks to be honest. Then again I have been used
>>>>> to
>>>>> being around
>>>>> slower projects that have released only every 2 or 3 years once 1 or 2
>>>>> hundred issues have
>>>>> been gathered into a release. And the release process itself takes
>>>>> weeks
>>>>> of work to
>>>>> achieve.
>>>>>
>>>>> Therefore ignore me, 3 issues seems like doing a days work, then
>>>>> release,
>>>>> then another days
>>>>> work, then release etc ...
>>>>>
>>>>>
>>>> Given a very quick count, the apache maven project contains something
>>>> like
>>>> 90 individually deployable and separately votable artifacts. Our users
>>>> upgrade these components individually according to need. Each component
>>>> is
>>>> individually tested and voted for; maven is not a monolithic application
>>>> and
>>>> should not be released as one.
>>>>
>>>> The downside of this componentization is that sometimes fixing a single
>>>> issue leads to the redeployment of multiple artifacts, at the moment I'm
>>>> working on 1 issue that will require the
>>>> redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere)
>>>> before it's closed in its full extent. Most likely I'll have votes for 2
>>>> of
>>>> these "soon" and I'll just let the remaining 4 roll out
>>>> together with releases planned by others. But in this context I simply
>>>> refuse to consider if a single release vote is too large or too small.
>>>>
>>>> From an agile perspective there's potential to getting a lot more
>>>> issues
>>>> fixed with a single year than the kind of project you mention. I have no
>>>> specific stats but I assume we fix at least a thousand issues every
>>>> year.
>>>>
>>>> Some of our projects have sufficiently good automated test coverage that
>>>> I
>>>> suspect we could allow incremental .1 releases to go without a vote
>>>> entirely. I'm not sure if this is something we're even allowed to
>>>> consider
>>>> ;) (Surefire would probably qualify, assuming we did some kind of
>>>> formalized
>>>> "continious production" kind of review)
>>>>
>>>> I think ideally we should release every top-level component every 6
>>>> weeks
>>>> or so. But that means we'd have 1-3 votes every day ;)
>>>>
>>>>
>>>> Kristian
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail:
>>>> dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: ranges and cascading releases was: [VOTE]: release maven-changes-plugin
2.6
Posted by Kristian Rosenvold <kr...@gmail.com>.
Technically I'd get away with updating 2-3 artifacts, but I'd end up
writing a cookbook on how to add a crapload of dependencies to the
plugins in question and answering on the mailing list and irc, and in
the end we'd have a ton of poms lying around with 3 overridden
dependencies in 4-5 plugins. So as as service to our end users I think
the fair thing is to release new versions. Now given that we manage to
maintain an "average" release schedule of 4-8 weeks, I would probably
just ignore releasing the plugin, but currently I think our release
schedules are driven by itches like mine. So I suppose we *could* solve
this by just assigning regular releases to committers. Personally I
don't /mind/ taking responsibility for releasing 2-3 plugins every 6-8
weeks if I knew someone else did the others.
I think version ranges for plugins are fairly dangerous because you'll
be removing the determinism in the build. Even though you lock down
plugin versions, you risk getting a new version of maven-shared-foobar
any day. I just need introduce *1* platform specific bug in
maven-shared-foobar to paralyze the entire community of "windows" users.
I've seen this happen in other projects that (for instance) have *no*
committers working on windows (yes, it's becoming fairly commonplace).
Kristian
Den 21.06.2011 02:38, skrev Brett Porter:
> Kristian can describe in more detail what he's working on, but not all changes take 8 artifact changes. In this case I think it's both that it's something that affects multiple things (rather than dependencies), and also a couple of things that have been broken down to one too separate many artifacts (like plexus-compiler, which I think is only ever used in the compiler plugin). Those sorts of exercises should actually help us understand if the right type of modularity has been applied.
>
> - Brett
>
> On 21/06/2011, at 6:27 AM, Mark Derricutt wrote:
>
>> Wow - that seems like a hell of a lot of releases having to be made...
>>
>> This post is probably drifting off topic but the thing that strikes me here
>> is that this is the exact reason why maven supports version ranges - so that
>> you don't have to make a plethora of rolling releases just because one
>> change was made downstream.
>>
>> It's no wonder a lot of version range bugs in maven never get fixed if none
>> of the plugins or maven itself actually uses them. Of course this only
>> solves the problem where an upstream release contains non-breaking changes
>> for its downstream users which hopefully, for bug fixes would be more often
>> than not.
>>
>> Locking down versions is good for third party dependencies, but I'm very
>> much of the mind that ranges should be used for sibings, would certainly
>> solve the problem of transitive release blowouts.
>>
>>
>> --
>> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
>> Porcupine Tree
>>
>>
>> On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold<
>> kristian.rosenvold@gmail.com> wrote:
>>
>>>
>>> Den 19.06.2011 23:08, skrev Gavin McDonald:
>>>
>>>
>>>> I would be happy with weeks to be honest. Then again I have been used to
>>>> being around
>>>> slower projects that have released only every 2 or 3 years once 1 or 2
>>>> hundred issues have
>>>> been gathered into a release. And the release process itself takes weeks
>>>> of work to
>>>> achieve.
>>>>
>>>> Therefore ignore me, 3 issues seems like doing a days work, then release,
>>>> then another days
>>>> work, then release etc ...
>>>>
>>>>
>>> Given a very quick count, the apache maven project contains something like
>>> 90 individually deployable and separately votable artifacts. Our users
>>> upgrade these components individually according to need. Each component is
>>> individually tested and voted for; maven is not a monolithic application and
>>> should not be released as one.
>>>
>>> The downside of this componentization is that sometimes fixing a single
>>> issue leads to the redeployment of multiple artifacts, at the moment I'm
>>> working on 1 issue that will require the
>>> redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere)
>>> before it's closed in its full extent. Most likely I'll have votes for 2 of
>>> these "soon" and I'll just let the remaining 4 roll out
>>> together with releases planned by others. But in this context I simply
>>> refuse to consider if a single release vote is too large or too small.
>>>
>>> From an agile perspective there's potential to getting a lot more issues
>>> fixed with a single year than the kind of project you mention. I have no
>>> specific stats but I assume we fix at least a thousand issues every year.
>>>
>>> Some of our projects have sufficiently good automated test coverage that I
>>> suspect we could allow incremental .1 releases to go without a vote
>>> entirely. I'm not sure if this is something we're even allowed to consider
>>> ;) (Surefire would probably qualify, assuming we did some kind of formalized
>>> "continious production" kind of review)
>>>
>>> I think ideally we should release every top-level component every 6 weeks
>>> or so. But that means we'd have 1-3 votes every day ;)
>>>
>>>
>>> Kristian
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: ranges and cascading releases was: [VOTE]: release maven-changes-plugin 2.6
Posted by Brett Porter <br...@apache.org>.
Kristian can describe in more detail what he's working on, but not all changes take 8 artifact changes. In this case I think it's both that it's something that affects multiple things (rather than dependencies), and also a couple of things that have been broken down to one too separate many artifacts (like plexus-compiler, which I think is only ever used in the compiler plugin). Those sorts of exercises should actually help us understand if the right type of modularity has been applied.
- Brett
On 21/06/2011, at 6:27 AM, Mark Derricutt wrote:
> Wow - that seems like a hell of a lot of releases having to be made...
>
> This post is probably drifting off topic but the thing that strikes me here
> is that this is the exact reason why maven supports version ranges - so that
> you don't have to make a plethora of rolling releases just because one
> change was made downstream.
>
> It's no wonder a lot of version range bugs in maven never get fixed if none
> of the plugins or maven itself actually uses them. Of course this only
> solves the problem where an upstream release contains non-breaking changes
> for its downstream users which hopefully, for bug fixes would be more often
> than not.
>
> Locking down versions is good for third party dependencies, but I'm very
> much of the mind that ranges should be used for sibings, would certainly
> solve the problem of transitive release blowouts.
>
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>
> On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold <
> kristian.rosenvold@gmail.com> wrote:
>
>>
>>
>> Den 19.06.2011 23:08, skrev Gavin McDonald:
>>
>>
>>> I would be happy with weeks to be honest. Then again I have been used to
>>> being around
>>> slower projects that have released only every 2 or 3 years once 1 or 2
>>> hundred issues have
>>> been gathered into a release. And the release process itself takes weeks
>>> of work to
>>> achieve.
>>>
>>> Therefore ignore me, 3 issues seems like doing a days work, then release,
>>> then another days
>>> work, then release etc ...
>>>
>>>
>> Given a very quick count, the apache maven project contains something like
>> 90 individually deployable and separately votable artifacts. Our users
>> upgrade these components individually according to need. Each component is
>> individually tested and voted for; maven is not a monolithic application and
>> should not be released as one.
>>
>> The downside of this componentization is that sometimes fixing a single
>> issue leads to the redeployment of multiple artifacts, at the moment I'm
>> working on 1 issue that will require the
>> redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere)
>> before it's closed in its full extent. Most likely I'll have votes for 2 of
>> these "soon" and I'll just let the remaining 4 roll out
>> together with releases planned by others. But in this context I simply
>> refuse to consider if a single release vote is too large or too small.
>>
>> From an agile perspective there's potential to getting a lot more issues
>> fixed with a single year than the kind of project you mention. I have no
>> specific stats but I assume we fix at least a thousand issues every year.
>>
>> Some of our projects have sufficiently good automated test coverage that I
>> suspect we could allow incremental .1 releases to go without a vote
>> entirely. I'm not sure if this is something we're even allowed to consider
>> ;) (Surefire would probably qualify, assuming we did some kind of formalized
>> "continious production" kind of review)
>>
>> I think ideally we should release every top-level component every 6 weeks
>> or so. But that means we'd have 1-3 votes every day ;)
>>
>>
>> Kristian
>>
>>
>>
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Mark Derricutt <ma...@talios.com>.
Wow - that seems like a hell of a lot of releases having to be made...
This post is probably drifting off topic but the thing that strikes me here
is that this is the exact reason why maven supports version ranges - so that
you don't have to make a plethora of rolling releases just because one
change was made downstream.
It's no wonder a lot of version range bugs in maven never get fixed if none
of the plugins or maven itself actually uses them. Of course this only
solves the problem where an upstream release contains non-breaking changes
for its downstream users which hopefully, for bug fixes would be more often
than not.
Locking down versions is good for third party dependencies, but I'm very
much of the mind that ranges should be used for sibings, would certainly
solve the problem of transitive release blowouts.
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold <
kristian.rosenvold@gmail.com> wrote:
>
>
> Den 19.06.2011 23:08, skrev Gavin McDonald:
>
>
>> I would be happy with weeks to be honest. Then again I have been used to
>> being around
>> slower projects that have released only every 2 or 3 years once 1 or 2
>> hundred issues have
>> been gathered into a release. And the release process itself takes weeks
>> of work to
>> achieve.
>>
>> Therefore ignore me, 3 issues seems like doing a days work, then release,
>> then another days
>> work, then release etc ...
>>
>>
> Given a very quick count, the apache maven project contains something like
> 90 individually deployable and separately votable artifacts. Our users
> upgrade these components individually according to need. Each component is
> individually tested and voted for; maven is not a monolithic application and
> should not be released as one.
>
> The downside of this componentization is that sometimes fixing a single
> issue leads to the redeployment of multiple artifacts, at the moment I'm
> working on 1 issue that will require the
> redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere)
> before it's closed in its full extent. Most likely I'll have votes for 2 of
> these "soon" and I'll just let the remaining 4 roll out
> together with releases planned by others. But in this context I simply
> refuse to consider if a single release vote is too large or too small.
>
> From an agile perspective there's potential to getting a lot more issues
> fixed with a single year than the kind of project you mention. I have no
> specific stats but I assume we fix at least a thousand issues every year.
>
> Some of our projects have sufficiently good automated test coverage that I
> suspect we could allow incremental .1 releases to go without a vote
> entirely. I'm not sure if this is something we're even allowed to consider
> ;) (Surefire would probably qualify, assuming we did some kind of formalized
> "continious production" kind of review)
>
> I think ideally we should release every top-level component every 6 weeks
> or so. But that means we'd have 1-3 votes every day ;)
>
>
> Kristian
>
>
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Kristian Rosenvold <kr...@gmail.com>.
Den 19.06.2011 23:08, skrev Gavin McDonald:
>
> I would be happy with weeks to be honest. Then again I have been used to being around
> slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have
> been gathered into a release. And the release process itself takes weeks of work to
> achieve.
>
> Therefore ignore me, 3 issues seems like doing a days work, then release, then another days
> work, then release etc ...
>
Given a very quick count, the apache maven project contains something
like 90 individually deployable and separately votable artifacts. Our
users upgrade these components individually according to need. Each
component is individually tested and voted for; maven is not a
monolithic application and should not be released as one.
The downside of this componentization is that sometimes fixing a single
issue leads to the redeployment of multiple artifacts, at the moment I'm
working on 1 issue that will require the
redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere)
before it's closed in its full extent. Most likely I'll have votes for 2
of these "soon" and I'll just let the remaining 4 roll out
together with releases planned by others. But in this context I simply
refuse to consider if a single release vote is too large or too small.
From an agile perspective there's potential to getting a lot more
issues fixed with a single year than the kind of project you mention. I
have no specific stats but I assume we fix at least a thousand issues
every year.
Some of our projects have sufficiently good automated test coverage that
I suspect we could allow incremental .1 releases to go without a vote
entirely. I'm not sure if this is something we're even allowed to
consider ;) (Surefire would probably qualify, assuming we did some kind
of formalized "continious production" kind of review)
I think ideally we should release every top-level component every 6
weeks or so. But that means we'd have 1-3 votes every day ;)
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [VOTE]: release maven-changes-plugin 2.6
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Mark Derricutt [mailto:mark@talios.com]
> Sent: Sunday, 19 June 2011 9:37 PM
> To: Maven Developers List; gavin@16degrees.com.au
> Subject: Re: [VOTE]: release maven-changes-plugin 2.6
>
> I'd rather see a release with 3 bug fixes if they code base is idle than see not
> see a release for weeks/months whilst someone waits for N more issues to
> be resolved.
I would be happy with weeks to be honest. Then again I have been used to being around
slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have
been gathered into a release. And the release process itself takes weeks of work to
achieve.
Therefore ignore me, 3 issues seems like doing a days work, then release, then another days
work, then release etc ...
Gav...
>
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>
> On Sun, Jun 19, 2011 at 8:34 PM, Gavin McDonald
> <ga...@16degrees.com.au>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.
> >
> > 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&jqlQuery=
> > >
> 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.html
> > >
> > > 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
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Mark Derricutt <ma...@talios.com>.
I'd rather see a release with 3 bug fixes if they code base is idle than see
not see a release for weeks/months whilst someone waits for N more issues to
be resolved.
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On Sun, Jun 19, 2011 at 8:34 PM, Gavin McDonald <ga...@16degrees.com.au>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.
>
> 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&jqlQuery=
> > 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.html
> >
> > 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
>
>
Re: RE: [VOTE]: release maven-changes-plugin 2.6
Posted by Benson Margulies <bi...@gmail.com>.
1: This [VOTE] is cancelled due to a merge snafu in the prep.
2: for Gavin: I spent several days fixing up a very broken feature to
render the plugin actually usable with customized JIRA installations.
I want to put that work to work in the real world, and I didn't see
any other outstanding issues that I felt qualified to tackle straight
off. I also invited the dev@ and pmc@ community to comment on the
proposal to make a release several days before I started it, and
received no doubts.
If people would prefer to call it 2.5.1 tell me now, but I think that
the amount of code furniture movement, pace the small JIRA count,
justifies 2.6.
On Sun, Jun 19, 2011 at 5:56 AM, Stephen Connolly
<st...@gmail.com> wrote:
> don't knock somebody who is taking the time and effort to actually run a
> release.
>
> any improvement is an improvement... you could quibble that maybe it should
> have been a 2.5.1 and not a 2.6 but it is down to the person who steps up to
> make the release.
>
> speaking with my pmc hat on, any improvement merrits a release... the
> decision as to whether to take that effort is down to the individual
> committer who steps up. it may be that benson needs the release in another
> project, so what you see as trivial may be a blocker to somebody else
> (personally in those cases I usually add a ref to the project needing the
> fast release, but there is no requirement to have such a ref).
>
> lets keep things positive, and benson, keep up the hard work
>
> I'll review the release when at a computer where I can test it
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on the
> screen
> On 19 Jun 2011 09:35, "Gavin McDonald" <ga...@16degrees.com.au> 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.
>>
>> 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&jqlQuery=
>>> 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.html
>>>
>>> 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
Re: RE: [VOTE]: release maven-changes-plugin 2.6
Posted by Stephen Connolly <st...@gmail.com>.
don't knock somebody who is taking the time and effort to actually run a
release.
any improvement is an improvement... you could quibble that maybe it should
have been a 2.5.1 and not a 2.6 but it is down to the person who steps up to
make the release.
speaking with my pmc hat on, any improvement merrits a release... the
decision as to whether to take that effort is down to the individual
committer who steps up. it may be that benson needs the release in another
project, so what you see as trivial may be a blocker to somebody else
(personally in those cases I usually add a ref to the project needing the
fast release, but there is no requirement to have such a ref).
lets keep things positive, and benson, keep up the hard work
I'll review the release when at a computer where I can test it
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 19 Jun 2011 09:35, "Gavin McDonald" <ga...@16degrees.com.au> 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.
>
> 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&jqlQuery=
>> 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.html
>>
>> 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
>
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Benson Margulies <bi...@gmail.com>.
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: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
>> <st...@gmail.com> wrote:
>> > On 20 June 2011 10:48, Gavin McDonald <ga...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Lukas Theussl <lt...@apache.org>.
Gavin McDonald wrote:
>
>
>> -----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 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
>> <st...@gmail.com> wrote:
>>> On 20 June 2011 10:48, Gavin McDonald<ga...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [VOTE]: release maven-changes-plugin 2.6
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----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
> <st...@gmail.com> wrote:
> > On 20 June 2011 10:48, Gavin McDonald <ga...@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
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Benson Margulies <bi...@gmail.com>.
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.
2: The amount of developer work that goes in is not proportional to
the number of JIRAs that come out.
3: The amount of user value that comes out is not proportional to the
number of JIRAs that go in.
4: An Apache principle is to encourage people to scratch their itches.
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.
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.
Is there some particular reason why you've chosen to blow a whistle
about this particular question?
--benson
On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly
<st...@gmail.com> wrote:
> On 20 June 2011 10:48, Gavin McDonald <ga...@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&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-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
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Stephen Connolly <st...@gmail.com>.
On 20 June 2011 10:48, Gavin McDonald <ga...@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&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-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
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Lukas Theussl <lt...@apache.org>.
Gavin,
Don't take it personal. I have expressed my opinion like you have
expressed yours, and we are both entitled to do so. But you have to
realize that your comments were taken with offence by some developers. I
have been with maven for several years now, I know we have taken
criticism for not releasing often enough, for releasing incomplete
stuff, for releasing broken stuff, for releasing undocumented stuff; but
this is the first time I remember that we take some heat for releasing
too often. I guess I simply still have to learn how to deal with it! :)
-Lukas
Gavin McDonald 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.
>
> What do you base your vote on exactly?
>
> 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.
>
> 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.
>
> 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-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
RE: [VOTE]: release maven-changes-plugin 2.6
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----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.
What do you base your vote on exactly?
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.
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.
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-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
Re: [VOTE]: release maven-changes-plugin 2.6
Posted by Lukas Theussl <lt...@apache.org>.
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?
Seriously, I think this posting will easily make it on our list of 10
most pointless contributions of the year. When to call a vote for a
release is solely the decision of the release manager, and the number of
issues is simply irrelevant.
-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&jqlQuery=
>> 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.html
>>
>> 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
RE: [VOTE]: release maven-changes-plugin 2.6
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----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.
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&jqlQuery=
> 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.html
>
> 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