You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2011/02/02 12:16:57 UTC
[DISCUSS] Re-trying releases
Over the past two years, I've been doing several releases in Felix and
i've re-rolled some with the same version without any problems.
I don't see any mention about not reusing the same number twice in the
release process:
http://felix.apache.org/site/release-management-nexus.html
What's the driver behing that ?
Until those releases are published, poeple accessing those are fully
aware of waht they are, so I don't see that as a problem.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Re-trying releases
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am Mittwoch, den 02.02.2011, 14:01 +0000 schrieb Guillaume Nodet:
> The fact you voted -1 puts a lot of pressure on me if I want to go to
> the majority in order to have those released ;-)
Probably yes. So I have to apologize to have rushed in with a
would-be-veto. I should rather only have raised my concern without
placing a vote.
> Last, remember each PMC decides on its own rules to govern its project.
Right -- to a certain degree. There are things a PMC cannot decide on.
And this is what makes the ASF strong.
> So the fact Roy sent an email on Jackrabbit doesn't make it an
> official policy for the ASF (and the ASF itself doesn't care about
> such technical details).
Since I could not come up with any official policy and assuming that
thus there is none, I have to agree with you here ...
>
> I'll re-roll those releases,
Thanks a lot.
> but I'd like things to be agreed upon
> *and* documented at some point.
Agreed.
My opinion is to state, that each vote must be with a new, increased
version number regardless of the outcome (success or failure) or earlier
votes of the same project.
Regards
Felix
>
> On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
> > On Wed, Feb 2, 2011 at 14:18, Felix Meschberger <fm...@adobe.com> wrote:
> >> Hi,
> >>
> >> My vetoes (actually there is no veto in a release vote since this is a
> >> majority vote)
> >
> > I know there's no vetoes in releases, but the goal is usually to
> > gather a consensus.
> > The fact you voted -1 puts a lot of pressure on me if I want to go to
> > the majority in order to have those released ;-)
> >
> >> are grounded on a message Roy Fielding once sent to the
> >> Jackrabbit list [1]:
> >>
> >>> The problem with doing all of our laundry in public is that the public
> >>> often download our unreleased packages even when we tell them not to.
> >>> For that reason, most Apache projects increment the patch-level number
> >>> each time a new package is produced (releases do not need to be
> >>> sequential).
> >
> > I suppose that depends on the definition of "most". Over the dozen of
> > projects I'm involved at the ASF, this is the first time I see that.
> > Maybe for projects like httpd that was the case, but I don't expect
> > many people that aren't felix committers to have downloaded those
> > released in the last 48 hours, so I still stand by the fact that in
> > our case, people are very aware that the jars aren't official yet.
> >
> > Anyway, if that's us becoming an official Felix project policy, I'd
> > like that to be written somewhere. Oral tradition is not really good
> > for newcomers ;-)
> >
> >>
> >> Unfortunately I cannot readily find the written rule for this, but this
> >> makes perfect sense to me, which is why I would prefer to get a new
> >> version number. Which is also why I always choose a new version number
> >> for a release vote after I had to cancel a vote.
> >>
> >> Regards
> >> Felix
> >>
> >> [1] http://markmail.org/message/533ybky6pqwwc2is
> >>
> >> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
> >>> Over the past two years, I've been doing several releases in Felix and
> >>> i've re-rolled some with the same version without any problems.
> >>> I don't see any mention about not reusing the same number twice in the
> >>> release process:
> >>> http://felix.apache.org/site/release-management-nexus.html
> >>> What's the driver behing that ?
> >>>
> >>> Until those releases are published, poeple accessing those are fully
> >>> aware of waht they are, so I don't see that as a problem.
> >>>
> >>
> >>
> >>
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
>
>
Re: [DISCUSS] Re-trying releases
Posted by Guillaume Nodet <gn...@gmail.com>.
Fair enough. I'll start a vote now.
On Fri, Feb 4, 2011 at 09:39, Carsten Ziegeler <cz...@apache.org> wrote:
> Guillaume Nodet wrote
>> On Fri, Feb 4, 2011 at 02:52, Richard S. Hall <he...@ungoverned.org> wrote:
>>>
>>> If enough people respond maybe we can reach some sort of consensus...or else
>>> we could call a vote on it.
>>
>> Can other felix members speak here ?
>>
> I guess we don't find consensus by just discussing :) Some of us prefer
> it this way, others the other way. I prefer increasing the version
> number for each retry, it requires no additional work (except changing
> the version in jira) and makes it easier to track if people are using
> failed releases. Sure, comparing the hash of the binary artifact would
> solve this as well, but just looking at the version number is soo easy :)
>
> If - as a project - we agree to use the same version number for retries
> I'm ok with as well.
>
> But I agree we should do this consistently and just write it down
> somewhere. So let's call a vote and the majority wins :)
>
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Re-trying releases
Posted by Peter Kriens <pe...@aqute.biz>.
If the bits are identical ... no increment is necessary. If the bits differ ... increment it.
Kind regards,
Peter Kriens
On 8 feb 2011, at 19:11, Richard S. Hall wrote:
> On 2/8/11 13:04, Richard S. Hall wrote:
>> On 2/8/11 12:29, Peter Kriens wrote:
>>> New version number for any reason makes a lot of sense. A bsn + version must be as unique as a SHA-1 hashcode of the bundle.
>>
>> I think everyone agrees that a new version number should always be used for every release. The issue here is about a release that was never released because it was canceled for some reason during the voting period.
>
> After re-reading your message, I read "reason" as "release"...
>
> However, the tricky part is as I described...at Apache there is no release without a proper vote, so the question is, do we need the version number to reflect these failed attempts?
>
> Give the ongoing vote on this, it doesn't look like we have any clear consensus. As a result, I'm happy to let the person doing the release decide...
>
> -> richard
>
>>
>> -> richard
>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>> On 4 feb 2011, at 09:39, Carsten Ziegeler wrote:
>>>
>>>> Guillaume Nodet wrote
>>>>> On Fri, Feb 4, 2011 at 02:52, Richard S. Hall<he...@ungoverned.org> wrote:
>>>>>> If enough people respond maybe we can reach some sort of consensus...or else
>>>>>> we could call a vote on it.
>>>>> Can other felix members speak here ?
>>>>>
>>>> I guess we don't find consensus by just discussing :) Some of us prefer
>>>> it this way, others the other way. I prefer increasing the version
>>>> number for each retry, it requires no additional work (except changing
>>>> the version in jira) and makes it easier to track if people are using
>>>> failed releases. Sure, comparing the hash of the binary artifact would
>>>> solve this as well, but just looking at the version number is soo easy :)
>>>>
>>>> If - as a project - we agree to use the same version number for retries
>>>> I'm ok with as well.
>>>>
>>>> But I agree we should do this consistently and just write it down
>>>> somewhere. So let's call a vote and the majority wins :)
>>>>
>>>> Carsten
>>>> --
>>>> Carsten Ziegeler
>>>> cziegeler@apache.org
Re: [DISCUSS] Re-trying releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/8/11 13:04, Richard S. Hall wrote:
> On 2/8/11 12:29, Peter Kriens wrote:
>> New version number for any reason makes a lot of sense. A bsn +
>> version must be as unique as a SHA-1 hashcode of the bundle.
>
> I think everyone agrees that a new version number should always be
> used for every release. The issue here is about a release that was
> never released because it was canceled for some reason during the
> voting period.
After re-reading your message, I read "reason" as "release"...
However, the tricky part is as I described...at Apache there is no
release without a proper vote, so the question is, do we need the
version number to reflect these failed attempts?
Give the ongoing vote on this, it doesn't look like we have any clear
consensus. As a result, I'm happy to let the person doing the release
decide...
-> richard
>
> -> richard
>
>> Kind regards,
>>
>> Peter Kriens
>>
>> On 4 feb 2011, at 09:39, Carsten Ziegeler wrote:
>>
>>> Guillaume Nodet wrote
>>>> On Fri, Feb 4, 2011 at 02:52, Richard S.
>>>> Hall<he...@ungoverned.org> wrote:
>>>>> If enough people respond maybe we can reach some sort of
>>>>> consensus...or else
>>>>> we could call a vote on it.
>>>> Can other felix members speak here ?
>>>>
>>> I guess we don't find consensus by just discussing :) Some of us prefer
>>> it this way, others the other way. I prefer increasing the version
>>> number for each retry, it requires no additional work (except changing
>>> the version in jira) and makes it easier to track if people are using
>>> failed releases. Sure, comparing the hash of the binary artifact would
>>> solve this as well, but just looking at the version number is soo
>>> easy :)
>>>
>>> If - as a project - we agree to use the same version number for retries
>>> I'm ok with as well.
>>>
>>> But I agree we should do this consistently and just write it down
>>> somewhere. So let's call a vote and the majority wins :)
>>>
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
Re: [DISCUSS] Re-trying releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/8/11 12:29, Peter Kriens wrote:
> New version number for any reason makes a lot of sense. A bsn + version must be as unique as a SHA-1 hashcode of the bundle.
I think everyone agrees that a new version number should always be used
for every release. The issue here is about a release that was never
released because it was canceled for some reason during the voting period.
-> richard
> Kind regards,
>
> Peter Kriens
>
> On 4 feb 2011, at 09:39, Carsten Ziegeler wrote:
>
>> Guillaume Nodet wrote
>>> On Fri, Feb 4, 2011 at 02:52, Richard S. Hall<he...@ungoverned.org> wrote:
>>>> If enough people respond maybe we can reach some sort of consensus...or else
>>>> we could call a vote on it.
>>> Can other felix members speak here ?
>>>
>> I guess we don't find consensus by just discussing :) Some of us prefer
>> it this way, others the other way. I prefer increasing the version
>> number for each retry, it requires no additional work (except changing
>> the version in jira) and makes it easier to track if people are using
>> failed releases. Sure, comparing the hash of the binary artifact would
>> solve this as well, but just looking at the version number is soo easy :)
>>
>> If - as a project - we agree to use the same version number for retries
>> I'm ok with as well.
>>
>> But I agree we should do this consistently and just write it down
>> somewhere. So let's call a vote and the majority wins :)
>>
>> Carsten
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
Re: [DISCUSS] Re-trying releases
Posted by Peter Kriens <pe...@aqute.biz>.
New version number for any reason makes a lot of sense. A bsn + version must be as unique as a SHA-1 hashcode of the bundle.
Kind regards,
Peter Kriens
On 4 feb 2011, at 09:39, Carsten Ziegeler wrote:
> Guillaume Nodet wrote
>> On Fri, Feb 4, 2011 at 02:52, Richard S. Hall <he...@ungoverned.org> wrote:
>>>
>>> If enough people respond maybe we can reach some sort of consensus...or else
>>> we could call a vote on it.
>>
>> Can other felix members speak here ?
>>
> I guess we don't find consensus by just discussing :) Some of us prefer
> it this way, others the other way. I prefer increasing the version
> number for each retry, it requires no additional work (except changing
> the version in jira) and makes it easier to track if people are using
> failed releases. Sure, comparing the hash of the binary artifact would
> solve this as well, but just looking at the version number is soo easy :)
>
> If - as a project - we agree to use the same version number for retries
> I'm ok with as well.
>
> But I agree we should do this consistently and just write it down
> somewhere. So let's call a vote and the majority wins :)
>
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [DISCUSS] Re-trying releases
Posted by Carsten Ziegeler <cz...@apache.org>.
Guillaume Nodet wrote
> On Fri, Feb 4, 2011 at 02:52, Richard S. Hall <he...@ungoverned.org> wrote:
>>
>> If enough people respond maybe we can reach some sort of consensus...or else
>> we could call a vote on it.
>
> Can other felix members speak here ?
>
I guess we don't find consensus by just discussing :) Some of us prefer
it this way, others the other way. I prefer increasing the version
number for each retry, it requires no additional work (except changing
the version in jira) and makes it easier to track if people are using
failed releases. Sure, comparing the hash of the binary artifact would
solve this as well, but just looking at the version number is soo easy :)
If - as a project - we agree to use the same version number for retries
I'm ok with as well.
But I agree we should do this consistently and just write it down
somewhere. So let's call a vote and the majority wins :)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [DISCUSS] Re-trying releases
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Feb 4, 2011 at 02:52, Richard S. Hall <he...@ungoverned.org> wrote:
> On 2/3/11 20:39, David Jencks wrote:
>>
>> I think that if it's good enough for the rest of the maven ecosystem it's
>> good enough for felix. How is felix special?
>
> Felix is special because we think it is, so we make the rules based on what
> we want to do, not what someone else does.
>
That's really not a good answer ... I really don't think the Felix
project has any different requirements than the other projects I've
worked with to justify such rules.
I can get the one with the incremental bump between snapshots and the
release (because of the osgi versions comparison), though I do think
people are kinda fool if they deploy snapshots in production and I
don't care much about development environments. But snapshots are
public and can be out there for a few weeks or months whereas our
releases candidates are not really public (you really have to be on
the dev list to know about those) and short-lived (at most one week),
so people are welll aware of their status.
>> so I think rerolling releases and staging them to apache nexus for voting
>> with the same version number until a vote passes is just fine.
>
> As I said, I can go either way.
>
> If enough people respond maybe we can reach some sort of consensus...or else
> we could call a vote on it.
Can other felix members speak here ?
>
> -> richard
>
>> david jencks
>>
>> On Feb 2, 2011, at 7:34 AM, Richard S. Hall wrote:
>>
>>> On 2/2/11 10:09, Guillaume Nodet wrote:
>>>>
>>>> They should not have valid signatures. Signatures are supposed to be
>>>> always provided by the ASF infrastructure, else anybody can claim
>>>> being a valid release.
>>>
>>> Depends on how you want to define "valid". The signatures are valid, you
>>> will be able to verify that the release was signed by one of our committers.
>>> But the signature will not be on a valid release, which makes the signature
>>> invalid. But how would someone know unless they knew they were required to
>>> go to Apache and get the signature files?
>>>
>>> Still, though, I don't really care. Really I don't. :-)
>>>
>>> Decide on the rule and add it to our release page...
>>>
>>> -> richard
>>>
>>>> On Wed, Feb 2, 2011 at 16:00, Richard S. Hall<he...@ungoverned.org>
>>>> wrote:
>>>>>
>>>>> On 2/2/11 9:49, Felix Meschberger wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Am Mittwoch, den 02.02.2011, 14:42 +0000 schrieb Richard S. Hall:
>>>>>>>
>>>>>>> I think originally we were more strict on changing the version number
>>>>>>> after failed votes, but we've since backed off. The reason for not
>>>>>>> being
>>>>>>> as strict, if I recall, is that people can still download the failed
>>>>>>> version while it's available with the signatures and put them up on
>>>>>>> some
>>>>>>> web site and call them official and people wouldn't know because the
>>>>>>> signatures are valid. So, what are we really gaining by changing the
>>>>>>> version number?
>>>>>>
>>>>>> The problem is exactly, that people may grab these packages under vote
>>>>>> and put them up. We cancel the vote; rebuild the package with the same
>>>>>> version number; succeed and publish.
>>>>>>
>>>>>> At this point in time we not only have an invalid package uploaded
>>>>>> which
>>>>>> can be identified as invalid (there is no tag for the failed release
>>>>>> and
>>>>>> there is no vote success).
>>>>>>
>>>>>> Rather we have two instances of a package with the same version number
>>>>>> in the wild. One is invalid and one is official. But which is which ?
>>>>>
>>>>> I understand that argument, but we don't completely eliminate the
>>>>> confusion,
>>>>> since there is still a failed version in the wild with valid
>>>>> signatures. So,
>>>>> unless someone comes and does an audit of our releases and finds out
>>>>> there
>>>>> isn't one (and understands what this means), then they won't know that
>>>>> their
>>>>> release with valid signatures isn't valid.
>>>>>
>>>>> In the end, I can care less either way. But lately we haven't been as
>>>>> strict
>>>>> about this. I am fine with not worrying about it, but if others want to
>>>>> worry about it we can do that too.
>>>>>
>>>>> -> richard
>>>>>
>>>>>> I hope I did properly summarize the problem sketched by Roy.
>>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>> On 2/2/11 9:01, Guillaume Nodet wrote:
>>>>>>>>
>>>>>>>> Last, remember each PMC decides on its own rules to govern its
>>>>>>>> project.
>>>>>>>> So the fact Roy sent an email on Jackrabbit doesn't make it an
>>>>>>>> official policy for the ASF (and the ASF itself doesn't care about
>>>>>>>> such technical details).
>>>>>>>>
>>>>>>>> I'll re-roll those releases, but I'd like things to be agreed upon
>>>>>>>> *and* documented at some point.
>>>>>>>>
>>>>>>>> On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet<gn...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Feb 2, 2011 at 14:18, Felix Meschberger<fm...@adobe.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> My vetoes (actually there is no veto in a release vote since this
>>>>>>>>>> is a
>>>>>>>>>> majority vote)
>>>>>>>>>
>>>>>>>>> I know there's no vetoes in releases, but the goal is usually to
>>>>>>>>> gather a consensus.
>>>>>>>>> The fact you voted -1 puts a lot of pressure on me if I want to go
>>>>>>>>> to
>>>>>>>>> the majority in order to have those released ;-)
>>>>>>>>>
>>>>>>>>>> are grounded on a message Roy Fielding once sent to the
>>>>>>>>>> Jackrabbit list [1]:
>>>>>>>>>>
>>>>>>>>>>> The problem with doing all of our laundry in public is that the
>>>>>>>>>>> public
>>>>>>>>>>> often download our unreleased packages even when we tell them not
>>>>>>>>>>> to.
>>>>>>>>>>> For that reason, most Apache projects increment the patch-level
>>>>>>>>>>> number
>>>>>>>>>>> each time a new package is produced (releases do not need to be
>>>>>>>>>>> sequential).
>>>>>>>>>
>>>>>>>>> I suppose that depends on the definition of "most". Over the dozen
>>>>>>>>> of
>>>>>>>>> projects I'm involved at the ASF, this is the first time I see
>>>>>>>>> that.
>>>>>>>>> Maybe for projects like httpd that was the case, but I don't expect
>>>>>>>>> many people that aren't felix committers to have downloaded those
>>>>>>>>> released in the last 48 hours, so I still stand by the fact that in
>>>>>>>>> our case, people are very aware that the jars aren't official yet.
>>>>>>>>>
>>>>>>>>> Anyway, if that's us becoming an official Felix project policy, I'd
>>>>>>>>> like that to be written somewhere. Oral tradition is not really
>>>>>>>>> good
>>>>>>>>> for newcomers ;-)
>>>>>>>>>
>>>>>>>>>> Unfortunately I cannot readily find the written rule for this, but
>>>>>>>>>> this
>>>>>>>>>> makes perfect sense to me, which is why I would prefer to get a
>>>>>>>>>> new
>>>>>>>>>> version number. Which is also why I always choose a new version
>>>>>>>>>> number
>>>>>>>>>> for a release vote after I had to cancel a vote.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Felix
>>>>>>>>>>
>>>>>>>>>> [1] http://markmail.org/message/533ybky6pqwwc2is
>>>>>>>>>>
>>>>>>>>>> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
>>>>>>>>>>>
>>>>>>>>>>> Over the past two years, I've been doing several releases in
>>>>>>>>>>> Felix
>>>>>>>>>>> and
>>>>>>>>>>> i've re-rolled some with the same version without any problems.
>>>>>>>>>>> I don't see any mention about not reusing the same number twice
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>> release process:
>>>>>>>>>>> http://felix.apache.org/site/release-management-nexus.html
>>>>>>>>>>> What's the driver behing that ?
>>>>>>>>>>>
>>>>>>>>>>> Until those releases are published, poeple accessing those are
>>>>>>>>>>> fully
>>>>>>>>>>> aware of waht they are, so I don't see that as a problem.
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>> ------------------------
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>> ------------------------
>>>>>>>>> Open Source SOA
>>>>>>>>> http://fusesource.com
>>>>>>>>>
>>>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Re-trying releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/3/11 20:39, David Jencks wrote:
> I think that if it's good enough for the rest of the maven ecosystem it's good enough for felix. How is felix special?
Felix is special because we think it is, so we make the rules based on
what we want to do, not what someone else does.
> so I think rerolling releases and staging them to apache nexus for voting with the same version number until a vote passes is just fine.
As I said, I can go either way.
If enough people respond maybe we can reach some sort of consensus...or
else we could call a vote on it.
-> richard
> david jencks
>
> On Feb 2, 2011, at 7:34 AM, Richard S. Hall wrote:
>
>> On 2/2/11 10:09, Guillaume Nodet wrote:
>>> They should not have valid signatures. Signatures are supposed to be
>>> always provided by the ASF infrastructure, else anybody can claim
>>> being a valid release.
>> Depends on how you want to define "valid". The signatures are valid, you will be able to verify that the release was signed by one of our committers. But the signature will not be on a valid release, which makes the signature invalid. But how would someone know unless they knew they were required to go to Apache and get the signature files?
>>
>> Still, though, I don't really care. Really I don't. :-)
>>
>> Decide on the rule and add it to our release page...
>>
>> -> richard
>>
>>> On Wed, Feb 2, 2011 at 16:00, Richard S. Hall<he...@ungoverned.org> wrote:
>>>> On 2/2/11 9:49, Felix Meschberger wrote:
>>>>> Hi,
>>>>>
>>>>> Am Mittwoch, den 02.02.2011, 14:42 +0000 schrieb Richard S. Hall:
>>>>>> I think originally we were more strict on changing the version number
>>>>>> after failed votes, but we've since backed off. The reason for not being
>>>>>> as strict, if I recall, is that people can still download the failed
>>>>>> version while it's available with the signatures and put them up on some
>>>>>> web site and call them official and people wouldn't know because the
>>>>>> signatures are valid. So, what are we really gaining by changing the
>>>>>> version number?
>>>>> The problem is exactly, that people may grab these packages under vote
>>>>> and put them up. We cancel the vote; rebuild the package with the same
>>>>> version number; succeed and publish.
>>>>>
>>>>> At this point in time we not only have an invalid package uploaded which
>>>>> can be identified as invalid (there is no tag for the failed release and
>>>>> there is no vote success).
>>>>>
>>>>> Rather we have two instances of a package with the same version number
>>>>> in the wild. One is invalid and one is official. But which is which ?
>>>> I understand that argument, but we don't completely eliminate the confusion,
>>>> since there is still a failed version in the wild with valid signatures. So,
>>>> unless someone comes and does an audit of our releases and finds out there
>>>> isn't one (and understands what this means), then they won't know that their
>>>> release with valid signatures isn't valid.
>>>>
>>>> In the end, I can care less either way. But lately we haven't been as strict
>>>> about this. I am fine with not worrying about it, but if others want to
>>>> worry about it we can do that too.
>>>>
>>>> -> richard
>>>>
>>>>> I hope I did properly summarize the problem sketched by Roy.
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>> -> richard
>>>>>>
>>>>>> On 2/2/11 9:01, Guillaume Nodet wrote:
>>>>>>> Last, remember each PMC decides on its own rules to govern its project.
>>>>>>> So the fact Roy sent an email on Jackrabbit doesn't make it an
>>>>>>> official policy for the ASF (and the ASF itself doesn't care about
>>>>>>> such technical details).
>>>>>>>
>>>>>>> I'll re-roll those releases, but I'd like things to be agreed upon
>>>>>>> *and* documented at some point.
>>>>>>>
>>>>>>> On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>>>>> On Wed, Feb 2, 2011 at 14:18, Felix Meschberger<fm...@adobe.com>
>>>>>>>> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> My vetoes (actually there is no veto in a release vote since this is a
>>>>>>>>> majority vote)
>>>>>>>> I know there's no vetoes in releases, but the goal is usually to
>>>>>>>> gather a consensus.
>>>>>>>> The fact you voted -1 puts a lot of pressure on me if I want to go to
>>>>>>>> the majority in order to have those released ;-)
>>>>>>>>
>>>>>>>>> are grounded on a message Roy Fielding once sent to the
>>>>>>>>> Jackrabbit list [1]:
>>>>>>>>>
>>>>>>>>>> The problem with doing all of our laundry in public is that the
>>>>>>>>>> public
>>>>>>>>>> often download our unreleased packages even when we tell them not to.
>>>>>>>>>> For that reason, most Apache projects increment the patch-level
>>>>>>>>>> number
>>>>>>>>>> each time a new package is produced (releases do not need to be
>>>>>>>>>> sequential).
>>>>>>>> I suppose that depends on the definition of "most". Over the dozen of
>>>>>>>> projects I'm involved at the ASF, this is the first time I see that.
>>>>>>>> Maybe for projects like httpd that was the case, but I don't expect
>>>>>>>> many people that aren't felix committers to have downloaded those
>>>>>>>> released in the last 48 hours, so I still stand by the fact that in
>>>>>>>> our case, people are very aware that the jars aren't official yet.
>>>>>>>>
>>>>>>>> Anyway, if that's us becoming an official Felix project policy, I'd
>>>>>>>> like that to be written somewhere. Oral tradition is not really good
>>>>>>>> for newcomers ;-)
>>>>>>>>
>>>>>>>>> Unfortunately I cannot readily find the written rule for this, but
>>>>>>>>> this
>>>>>>>>> makes perfect sense to me, which is why I would prefer to get a new
>>>>>>>>> version number. Which is also why I always choose a new version number
>>>>>>>>> for a release vote after I had to cancel a vote.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Felix
>>>>>>>>>
>>>>>>>>> [1] http://markmail.org/message/533ybky6pqwwc2is
>>>>>>>>>
>>>>>>>>> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
>>>>>>>>>> Over the past two years, I've been doing several releases in Felix
>>>>>>>>>> and
>>>>>>>>>> i've re-rolled some with the same version without any problems.
>>>>>>>>>> I don't see any mention about not reusing the same number twice in
>>>>>>>>>> the
>>>>>>>>>> release process:
>>>>>>>>>> http://felix.apache.org/site/release-management-nexus.html
>>>>>>>>>> What's the driver behing that ?
>>>>>>>>>>
>>>>>>>>>> Until those releases are published, poeple accessing those are fully
>>>>>>>>>> aware of waht they are, so I don't see that as a problem.
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>
Re: [DISCUSS] Re-trying releases
Posted by David Jencks <da...@yahoo.com>.
I think that if it's good enough for the rest of the maven ecosystem it's good enough for felix. How is felix special?
so I think rerolling releases and staging them to apache nexus for voting with the same version number until a vote passes is just fine.
david jencks
On Feb 2, 2011, at 7:34 AM, Richard S. Hall wrote:
> On 2/2/11 10:09, Guillaume Nodet wrote:
>> They should not have valid signatures. Signatures are supposed to be
>> always provided by the ASF infrastructure, else anybody can claim
>> being a valid release.
>
> Depends on how you want to define "valid". The signatures are valid, you will be able to verify that the release was signed by one of our committers. But the signature will not be on a valid release, which makes the signature invalid. But how would someone know unless they knew they were required to go to Apache and get the signature files?
>
> Still, though, I don't really care. Really I don't. :-)
>
> Decide on the rule and add it to our release page...
>
> -> richard
>
>> On Wed, Feb 2, 2011 at 16:00, Richard S. Hall<he...@ungoverned.org> wrote:
>>> On 2/2/11 9:49, Felix Meschberger wrote:
>>>> Hi,
>>>>
>>>> Am Mittwoch, den 02.02.2011, 14:42 +0000 schrieb Richard S. Hall:
>>>>> I think originally we were more strict on changing the version number
>>>>> after failed votes, but we've since backed off. The reason for not being
>>>>> as strict, if I recall, is that people can still download the failed
>>>>> version while it's available with the signatures and put them up on some
>>>>> web site and call them official and people wouldn't know because the
>>>>> signatures are valid. So, what are we really gaining by changing the
>>>>> version number?
>>>> The problem is exactly, that people may grab these packages under vote
>>>> and put them up. We cancel the vote; rebuild the package with the same
>>>> version number; succeed and publish.
>>>>
>>>> At this point in time we not only have an invalid package uploaded which
>>>> can be identified as invalid (there is no tag for the failed release and
>>>> there is no vote success).
>>>>
>>>> Rather we have two instances of a package with the same version number
>>>> in the wild. One is invalid and one is official. But which is which ?
>>> I understand that argument, but we don't completely eliminate the confusion,
>>> since there is still a failed version in the wild with valid signatures. So,
>>> unless someone comes and does an audit of our releases and finds out there
>>> isn't one (and understands what this means), then they won't know that their
>>> release with valid signatures isn't valid.
>>>
>>> In the end, I can care less either way. But lately we haven't been as strict
>>> about this. I am fine with not worrying about it, but if others want to
>>> worry about it we can do that too.
>>>
>>> -> richard
>>>
>>>> I hope I did properly summarize the problem sketched by Roy.
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>> -> richard
>>>>>
>>>>> On 2/2/11 9:01, Guillaume Nodet wrote:
>>>>>> Last, remember each PMC decides on its own rules to govern its project.
>>>>>> So the fact Roy sent an email on Jackrabbit doesn't make it an
>>>>>> official policy for the ASF (and the ASF itself doesn't care about
>>>>>> such technical details).
>>>>>>
>>>>>> I'll re-roll those releases, but I'd like things to be agreed upon
>>>>>> *and* documented at some point.
>>>>>>
>>>>>> On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>>>> On Wed, Feb 2, 2011 at 14:18, Felix Meschberger<fm...@adobe.com>
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> My vetoes (actually there is no veto in a release vote since this is a
>>>>>>>> majority vote)
>>>>>>> I know there's no vetoes in releases, but the goal is usually to
>>>>>>> gather a consensus.
>>>>>>> The fact you voted -1 puts a lot of pressure on me if I want to go to
>>>>>>> the majority in order to have those released ;-)
>>>>>>>
>>>>>>>> are grounded on a message Roy Fielding once sent to the
>>>>>>>> Jackrabbit list [1]:
>>>>>>>>
>>>>>>>>> The problem with doing all of our laundry in public is that the
>>>>>>>>> public
>>>>>>>>> often download our unreleased packages even when we tell them not to.
>>>>>>>>> For that reason, most Apache projects increment the patch-level
>>>>>>>>> number
>>>>>>>>> each time a new package is produced (releases do not need to be
>>>>>>>>> sequential).
>>>>>>> I suppose that depends on the definition of "most". Over the dozen of
>>>>>>> projects I'm involved at the ASF, this is the first time I see that.
>>>>>>> Maybe for projects like httpd that was the case, but I don't expect
>>>>>>> many people that aren't felix committers to have downloaded those
>>>>>>> released in the last 48 hours, so I still stand by the fact that in
>>>>>>> our case, people are very aware that the jars aren't official yet.
>>>>>>>
>>>>>>> Anyway, if that's us becoming an official Felix project policy, I'd
>>>>>>> like that to be written somewhere. Oral tradition is not really good
>>>>>>> for newcomers ;-)
>>>>>>>
>>>>>>>> Unfortunately I cannot readily find the written rule for this, but
>>>>>>>> this
>>>>>>>> makes perfect sense to me, which is why I would prefer to get a new
>>>>>>>> version number. Which is also why I always choose a new version number
>>>>>>>> for a release vote after I had to cancel a vote.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Felix
>>>>>>>>
>>>>>>>> [1] http://markmail.org/message/533ybky6pqwwc2is
>>>>>>>>
>>>>>>>> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
>>>>>>>>> Over the past two years, I've been doing several releases in Felix
>>>>>>>>> and
>>>>>>>>> i've re-rolled some with the same version without any problems.
>>>>>>>>> I don't see any mention about not reusing the same number twice in
>>>>>>>>> the
>>>>>>>>> release process:
>>>>>>>>> http://felix.apache.org/site/release-management-nexus.html
>>>>>>>>> What's the driver behing that ?
>>>>>>>>>
>>>>>>>>> Until those releases are published, poeple accessing those are fully
>>>>>>>>> aware of waht they are, so I don't see that as a problem.
>>>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>
>>
Re: [DISCUSS] Re-trying releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/2/11 10:09, Guillaume Nodet wrote:
> They should not have valid signatures. Signatures are supposed to be
> always provided by the ASF infrastructure, else anybody can claim
> being a valid release.
Depends on how you want to define "valid". The signatures are valid, you
will be able to verify that the release was signed by one of our
committers. But the signature will not be on a valid release, which
makes the signature invalid. But how would someone know unless they knew
they were required to go to Apache and get the signature files?
Still, though, I don't really care. Really I don't. :-)
Decide on the rule and add it to our release page...
-> richard
> On Wed, Feb 2, 2011 at 16:00, Richard S. Hall<he...@ungoverned.org> wrote:
>> On 2/2/11 9:49, Felix Meschberger wrote:
>>> Hi,
>>>
>>> Am Mittwoch, den 02.02.2011, 14:42 +0000 schrieb Richard S. Hall:
>>>> I think originally we were more strict on changing the version number
>>>> after failed votes, but we've since backed off. The reason for not being
>>>> as strict, if I recall, is that people can still download the failed
>>>> version while it's available with the signatures and put them up on some
>>>> web site and call them official and people wouldn't know because the
>>>> signatures are valid. So, what are we really gaining by changing the
>>>> version number?
>>> The problem is exactly, that people may grab these packages under vote
>>> and put them up. We cancel the vote; rebuild the package with the same
>>> version number; succeed and publish.
>>>
>>> At this point in time we not only have an invalid package uploaded which
>>> can be identified as invalid (there is no tag for the failed release and
>>> there is no vote success).
>>>
>>> Rather we have two instances of a package with the same version number
>>> in the wild. One is invalid and one is official. But which is which ?
>> I understand that argument, but we don't completely eliminate the confusion,
>> since there is still a failed version in the wild with valid signatures. So,
>> unless someone comes and does an audit of our releases and finds out there
>> isn't one (and understands what this means), then they won't know that their
>> release with valid signatures isn't valid.
>>
>> In the end, I can care less either way. But lately we haven't been as strict
>> about this. I am fine with not worrying about it, but if others want to
>> worry about it we can do that too.
>>
>> -> richard
>>
>>> I hope I did properly summarize the problem sketched by Roy.
>>>
>>> Regards
>>> Felix
>>>
>>>> -> richard
>>>>
>>>> On 2/2/11 9:01, Guillaume Nodet wrote:
>>>>> Last, remember each PMC decides on its own rules to govern its project.
>>>>> So the fact Roy sent an email on Jackrabbit doesn't make it an
>>>>> official policy for the ASF (and the ASF itself doesn't care about
>>>>> such technical details).
>>>>>
>>>>> I'll re-roll those releases, but I'd like things to be agreed upon
>>>>> *and* documented at some point.
>>>>>
>>>>> On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>>> On Wed, Feb 2, 2011 at 14:18, Felix Meschberger<fm...@adobe.com>
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> My vetoes (actually there is no veto in a release vote since this is a
>>>>>>> majority vote)
>>>>>> I know there's no vetoes in releases, but the goal is usually to
>>>>>> gather a consensus.
>>>>>> The fact you voted -1 puts a lot of pressure on me if I want to go to
>>>>>> the majority in order to have those released ;-)
>>>>>>
>>>>>>> are grounded on a message Roy Fielding once sent to the
>>>>>>> Jackrabbit list [1]:
>>>>>>>
>>>>>>>> The problem with doing all of our laundry in public is that the
>>>>>>>> public
>>>>>>>> often download our unreleased packages even when we tell them not to.
>>>>>>>> For that reason, most Apache projects increment the patch-level
>>>>>>>> number
>>>>>>>> each time a new package is produced (releases do not need to be
>>>>>>>> sequential).
>>>>>> I suppose that depends on the definition of "most". Over the dozen of
>>>>>> projects I'm involved at the ASF, this is the first time I see that.
>>>>>> Maybe for projects like httpd that was the case, but I don't expect
>>>>>> many people that aren't felix committers to have downloaded those
>>>>>> released in the last 48 hours, so I still stand by the fact that in
>>>>>> our case, people are very aware that the jars aren't official yet.
>>>>>>
>>>>>> Anyway, if that's us becoming an official Felix project policy, I'd
>>>>>> like that to be written somewhere. Oral tradition is not really good
>>>>>> for newcomers ;-)
>>>>>>
>>>>>>> Unfortunately I cannot readily find the written rule for this, but
>>>>>>> this
>>>>>>> makes perfect sense to me, which is why I would prefer to get a new
>>>>>>> version number. Which is also why I always choose a new version number
>>>>>>> for a release vote after I had to cancel a vote.
>>>>>>>
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>
>>>>>>> [1] http://markmail.org/message/533ybky6pqwwc2is
>>>>>>>
>>>>>>> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
>>>>>>>> Over the past two years, I've been doing several releases in Felix
>>>>>>>> and
>>>>>>>> i've re-rolled some with the same version without any problems.
>>>>>>>> I don't see any mention about not reusing the same number twice in
>>>>>>>> the
>>>>>>>> release process:
>>>>>>>> http://felix.apache.org/site/release-management-nexus.html
>>>>>>>> What's the driver behing that ?
>>>>>>>>
>>>>>>>> Until those releases are published, poeple accessing those are fully
>>>>>>>> aware of waht they are, so I don't see that as a problem.
>>>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>
>
Re: [DISCUSS] Re-trying releases
Posted by Guillaume Nodet <gn...@gmail.com>.
They should not have valid signatures. Signatures are supposed to be
always provided by the ASF infrastructure, else anybody can claim
being a valid release.
On Wed, Feb 2, 2011 at 16:00, Richard S. Hall <he...@ungoverned.org> wrote:
> On 2/2/11 9:49, Felix Meschberger wrote:
>>
>> Hi,
>>
>> Am Mittwoch, den 02.02.2011, 14:42 +0000 schrieb Richard S. Hall:
>>>
>>> I think originally we were more strict on changing the version number
>>> after failed votes, but we've since backed off. The reason for not being
>>> as strict, if I recall, is that people can still download the failed
>>> version while it's available with the signatures and put them up on some
>>> web site and call them official and people wouldn't know because the
>>> signatures are valid. So, what are we really gaining by changing the
>>> version number?
>>
>> The problem is exactly, that people may grab these packages under vote
>> and put them up. We cancel the vote; rebuild the package with the same
>> version number; succeed and publish.
>>
>> At this point in time we not only have an invalid package uploaded which
>> can be identified as invalid (there is no tag for the failed release and
>> there is no vote success).
>>
>> Rather we have two instances of a package with the same version number
>> in the wild. One is invalid and one is official. But which is which ?
>
> I understand that argument, but we don't completely eliminate the confusion,
> since there is still a failed version in the wild with valid signatures. So,
> unless someone comes and does an audit of our releases and finds out there
> isn't one (and understands what this means), then they won't know that their
> release with valid signatures isn't valid.
>
> In the end, I can care less either way. But lately we haven't been as strict
> about this. I am fine with not worrying about it, but if others want to
> worry about it we can do that too.
>
> -> richard
>
>> I hope I did properly summarize the problem sketched by Roy.
>>
>> Regards
>> Felix
>>
>>> -> richard
>>>
>>> On 2/2/11 9:01, Guillaume Nodet wrote:
>>>>
>>>> Last, remember each PMC decides on its own rules to govern its project.
>>>> So the fact Roy sent an email on Jackrabbit doesn't make it an
>>>> official policy for the ASF (and the ASF itself doesn't care about
>>>> such technical details).
>>>>
>>>> I'll re-roll those releases, but I'd like things to be agreed upon
>>>> *and* documented at some point.
>>>>
>>>> On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>>
>>>>> On Wed, Feb 2, 2011 at 14:18, Felix Meschberger<fm...@adobe.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> My vetoes (actually there is no veto in a release vote since this is a
>>>>>> majority vote)
>>>>>
>>>>> I know there's no vetoes in releases, but the goal is usually to
>>>>> gather a consensus.
>>>>> The fact you voted -1 puts a lot of pressure on me if I want to go to
>>>>> the majority in order to have those released ;-)
>>>>>
>>>>>> are grounded on a message Roy Fielding once sent to the
>>>>>> Jackrabbit list [1]:
>>>>>>
>>>>>>> The problem with doing all of our laundry in public is that the
>>>>>>> public
>>>>>>> often download our unreleased packages even when we tell them not to.
>>>>>>> For that reason, most Apache projects increment the patch-level
>>>>>>> number
>>>>>>> each time a new package is produced (releases do not need to be
>>>>>>> sequential).
>>>>>
>>>>> I suppose that depends on the definition of "most". Over the dozen of
>>>>> projects I'm involved at the ASF, this is the first time I see that.
>>>>> Maybe for projects like httpd that was the case, but I don't expect
>>>>> many people that aren't felix committers to have downloaded those
>>>>> released in the last 48 hours, so I still stand by the fact that in
>>>>> our case, people are very aware that the jars aren't official yet.
>>>>>
>>>>> Anyway, if that's us becoming an official Felix project policy, I'd
>>>>> like that to be written somewhere. Oral tradition is not really good
>>>>> for newcomers ;-)
>>>>>
>>>>>> Unfortunately I cannot readily find the written rule for this, but
>>>>>> this
>>>>>> makes perfect sense to me, which is why I would prefer to get a new
>>>>>> version number. Which is also why I always choose a new version number
>>>>>> for a release vote after I had to cancel a vote.
>>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>> [1] http://markmail.org/message/533ybky6pqwwc2is
>>>>>>
>>>>>> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
>>>>>>>
>>>>>>> Over the past two years, I've been doing several releases in Felix
>>>>>>> and
>>>>>>> i've re-rolled some with the same version without any problems.
>>>>>>> I don't see any mention about not reusing the same number twice in
>>>>>>> the
>>>>>>> release process:
>>>>>>> http://felix.apache.org/site/release-management-nexus.html
>>>>>>> What's the driver behing that ?
>>>>>>>
>>>>>>> Until those releases are published, poeple accessing those are fully
>>>>>>> aware of waht they are, so I don't see that as a problem.
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Re-trying releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/2/11 9:49, Felix Meschberger wrote:
> Hi,
>
> Am Mittwoch, den 02.02.2011, 14:42 +0000 schrieb Richard S. Hall:
>> I think originally we were more strict on changing the version number
>> after failed votes, but we've since backed off. The reason for not being
>> as strict, if I recall, is that people can still download the failed
>> version while it's available with the signatures and put them up on some
>> web site and call them official and people wouldn't know because the
>> signatures are valid. So, what are we really gaining by changing the
>> version number?
> The problem is exactly, that people may grab these packages under vote
> and put them up. We cancel the vote; rebuild the package with the same
> version number; succeed and publish.
>
> At this point in time we not only have an invalid package uploaded which
> can be identified as invalid (there is no tag for the failed release and
> there is no vote success).
>
> Rather we have two instances of a package with the same version number
> in the wild. One is invalid and one is official. But which is which ?
I understand that argument, but we don't completely eliminate the
confusion, since there is still a failed version in the wild with valid
signatures. So, unless someone comes and does an audit of our releases
and finds out there isn't one (and understands what this means), then
they won't know that their release with valid signatures isn't valid.
In the end, I can care less either way. But lately we haven't been as
strict about this. I am fine with not worrying about it, but if others
want to worry about it we can do that too.
-> richard
> I hope I did properly summarize the problem sketched by Roy.
>
> Regards
> Felix
>
>> -> richard
>>
>> On 2/2/11 9:01, Guillaume Nodet wrote:
>>> Last, remember each PMC decides on its own rules to govern its project.
>>> So the fact Roy sent an email on Jackrabbit doesn't make it an
>>> official policy for the ASF (and the ASF itself doesn't care about
>>> such technical details).
>>>
>>> I'll re-roll those releases, but I'd like things to be agreed upon
>>> *and* documented at some point.
>>>
>>> On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet<gn...@gmail.com> wrote:
>>>> On Wed, Feb 2, 2011 at 14:18, Felix Meschberger<fm...@adobe.com> wrote:
>>>>> Hi,
>>>>>
>>>>> My vetoes (actually there is no veto in a release vote since this is a
>>>>> majority vote)
>>>> I know there's no vetoes in releases, but the goal is usually to
>>>> gather a consensus.
>>>> The fact you voted -1 puts a lot of pressure on me if I want to go to
>>>> the majority in order to have those released ;-)
>>>>
>>>>> are grounded on a message Roy Fielding once sent to the
>>>>> Jackrabbit list [1]:
>>>>>
>>>>>> The problem with doing all of our laundry in public is that the public
>>>>>> often download our unreleased packages even when we tell them not to.
>>>>>> For that reason, most Apache projects increment the patch-level number
>>>>>> each time a new package is produced (releases do not need to be
>>>>>> sequential).
>>>> I suppose that depends on the definition of "most". Over the dozen of
>>>> projects I'm involved at the ASF, this is the first time I see that.
>>>> Maybe for projects like httpd that was the case, but I don't expect
>>>> many people that aren't felix committers to have downloaded those
>>>> released in the last 48 hours, so I still stand by the fact that in
>>>> our case, people are very aware that the jars aren't official yet.
>>>>
>>>> Anyway, if that's us becoming an official Felix project policy, I'd
>>>> like that to be written somewhere. Oral tradition is not really good
>>>> for newcomers ;-)
>>>>
>>>>> Unfortunately I cannot readily find the written rule for this, but this
>>>>> makes perfect sense to me, which is why I would prefer to get a new
>>>>> version number. Which is also why I always choose a new version number
>>>>> for a release vote after I had to cancel a vote.
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>> [1] http://markmail.org/message/533ybky6pqwwc2is
>>>>>
>>>>> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
>>>>>> Over the past two years, I've been doing several releases in Felix and
>>>>>> i've re-rolled some with the same version without any problems.
>>>>>> I don't see any mention about not reusing the same number twice in the
>>>>>> release process:
>>>>>> http://felix.apache.org/site/release-management-nexus.html
>>>>>> What's the driver behing that ?
>>>>>>
>>>>>> Until those releases are published, poeple accessing those are fully
>>>>>> aware of waht they are, so I don't see that as a problem.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>
Re: [DISCUSS] Re-trying releases
Posted by Guillaume Nodet <gn...@gmail.com>.
I think since issue has been solved a while ago by mandating all
artifacts have pgp / md5 signatures to identify if those are valid or
not. That's the whole (and only afaik) point of those additional
required files.
On Wed, Feb 2, 2011 at 15:49, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> Am Mittwoch, den 02.02.2011, 14:42 +0000 schrieb Richard S. Hall:
>> I think originally we were more strict on changing the version number
>> after failed votes, but we've since backed off. The reason for not being
>> as strict, if I recall, is that people can still download the failed
>> version while it's available with the signatures and put them up on some
>> web site and call them official and people wouldn't know because the
>> signatures are valid. So, what are we really gaining by changing the
>> version number?
>
> The problem is exactly, that people may grab these packages under vote
> and put them up. We cancel the vote; rebuild the package with the same
> version number; succeed and publish.
>
> At this point in time we not only have an invalid package uploaded which
> can be identified as invalid (there is no tag for the failed release and
> there is no vote success).
>
> Rather we have two instances of a package with the same version number
> in the wild. One is invalid and one is official. But which is which ?
>
> I hope I did properly summarize the problem sketched by Roy.
>
> Regards
> Felix
>
>>
>> -> richard
>>
>> On 2/2/11 9:01, Guillaume Nodet wrote:
>> > Last, remember each PMC decides on its own rules to govern its project.
>> > So the fact Roy sent an email on Jackrabbit doesn't make it an
>> > official policy for the ASF (and the ASF itself doesn't care about
>> > such technical details).
>> >
>> > I'll re-roll those releases, but I'd like things to be agreed upon
>> > *and* documented at some point.
>> >
>> > On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet<gn...@gmail.com> wrote:
>> >> On Wed, Feb 2, 2011 at 14:18, Felix Meschberger<fm...@adobe.com> wrote:
>> >>> Hi,
>> >>>
>> >>> My vetoes (actually there is no veto in a release vote since this is a
>> >>> majority vote)
>> >> I know there's no vetoes in releases, but the goal is usually to
>> >> gather a consensus.
>> >> The fact you voted -1 puts a lot of pressure on me if I want to go to
>> >> the majority in order to have those released ;-)
>> >>
>> >>> are grounded on a message Roy Fielding once sent to the
>> >>> Jackrabbit list [1]:
>> >>>
>> >>>> The problem with doing all of our laundry in public is that the public
>> >>>> often download our unreleased packages even when we tell them not to.
>> >>>> For that reason, most Apache projects increment the patch-level number
>> >>>> each time a new package is produced (releases do not need to be
>> >>>> sequential).
>> >> I suppose that depends on the definition of "most". Over the dozen of
>> >> projects I'm involved at the ASF, this is the first time I see that.
>> >> Maybe for projects like httpd that was the case, but I don't expect
>> >> many people that aren't felix committers to have downloaded those
>> >> released in the last 48 hours, so I still stand by the fact that in
>> >> our case, people are very aware that the jars aren't official yet.
>> >>
>> >> Anyway, if that's us becoming an official Felix project policy, I'd
>> >> like that to be written somewhere. Oral tradition is not really good
>> >> for newcomers ;-)
>> >>
>> >>> Unfortunately I cannot readily find the written rule for this, but this
>> >>> makes perfect sense to me, which is why I would prefer to get a new
>> >>> version number. Which is also why I always choose a new version number
>> >>> for a release vote after I had to cancel a vote.
>> >>>
>> >>> Regards
>> >>> Felix
>> >>>
>> >>> [1] http://markmail.org/message/533ybky6pqwwc2is
>> >>>
>> >>> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
>> >>>> Over the past two years, I've been doing several releases in Felix and
>> >>>> i've re-rolled some with the same version without any problems.
>> >>>> I don't see any mention about not reusing the same number twice in the
>> >>>> release process:
>> >>>> http://felix.apache.org/site/release-management-nexus.html
>> >>>> What's the driver behing that ?
>> >>>>
>> >>>> Until those releases are published, poeple accessing those are fully
>> >>>> aware of waht they are, so I don't see that as a problem.
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Guillaume Nodet
>> >> ------------------------
>> >> Blog: http://gnodet.blogspot.com/
>> >> ------------------------
>> >> Open Source SOA
>> >> http://fusesource.com
>> >>
>> >
>> >
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Re-trying releases
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am Mittwoch, den 02.02.2011, 14:42 +0000 schrieb Richard S. Hall:
> I think originally we were more strict on changing the version number
> after failed votes, but we've since backed off. The reason for not being
> as strict, if I recall, is that people can still download the failed
> version while it's available with the signatures and put them up on some
> web site and call them official and people wouldn't know because the
> signatures are valid. So, what are we really gaining by changing the
> version number?
The problem is exactly, that people may grab these packages under vote
and put them up. We cancel the vote; rebuild the package with the same
version number; succeed and publish.
At this point in time we not only have an invalid package uploaded which
can be identified as invalid (there is no tag for the failed release and
there is no vote success).
Rather we have two instances of a package with the same version number
in the wild. One is invalid and one is official. But which is which ?
I hope I did properly summarize the problem sketched by Roy.
Regards
Felix
>
> -> richard
>
> On 2/2/11 9:01, Guillaume Nodet wrote:
> > Last, remember each PMC decides on its own rules to govern its project.
> > So the fact Roy sent an email on Jackrabbit doesn't make it an
> > official policy for the ASF (and the ASF itself doesn't care about
> > such technical details).
> >
> > I'll re-roll those releases, but I'd like things to be agreed upon
> > *and* documented at some point.
> >
> > On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet<gn...@gmail.com> wrote:
> >> On Wed, Feb 2, 2011 at 14:18, Felix Meschberger<fm...@adobe.com> wrote:
> >>> Hi,
> >>>
> >>> My vetoes (actually there is no veto in a release vote since this is a
> >>> majority vote)
> >> I know there's no vetoes in releases, but the goal is usually to
> >> gather a consensus.
> >> The fact you voted -1 puts a lot of pressure on me if I want to go to
> >> the majority in order to have those released ;-)
> >>
> >>> are grounded on a message Roy Fielding once sent to the
> >>> Jackrabbit list [1]:
> >>>
> >>>> The problem with doing all of our laundry in public is that the public
> >>>> often download our unreleased packages even when we tell them not to.
> >>>> For that reason, most Apache projects increment the patch-level number
> >>>> each time a new package is produced (releases do not need to be
> >>>> sequential).
> >> I suppose that depends on the definition of "most". Over the dozen of
> >> projects I'm involved at the ASF, this is the first time I see that.
> >> Maybe for projects like httpd that was the case, but I don't expect
> >> many people that aren't felix committers to have downloaded those
> >> released in the last 48 hours, so I still stand by the fact that in
> >> our case, people are very aware that the jars aren't official yet.
> >>
> >> Anyway, if that's us becoming an official Felix project policy, I'd
> >> like that to be written somewhere. Oral tradition is not really good
> >> for newcomers ;-)
> >>
> >>> Unfortunately I cannot readily find the written rule for this, but this
> >>> makes perfect sense to me, which is why I would prefer to get a new
> >>> version number. Which is also why I always choose a new version number
> >>> for a release vote after I had to cancel a vote.
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>> [1] http://markmail.org/message/533ybky6pqwwc2is
> >>>
> >>> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
> >>>> Over the past two years, I've been doing several releases in Felix and
> >>>> i've re-rolled some with the same version without any problems.
> >>>> I don't see any mention about not reusing the same number twice in the
> >>>> release process:
> >>>> http://felix.apache.org/site/release-management-nexus.html
> >>>> What's the driver behing that ?
> >>>>
> >>>> Until those releases are published, poeple accessing those are fully
> >>>> aware of waht they are, so I don't see that as a problem.
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >>
> >
> >
Re: [DISCUSS] Re-trying releases
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I think originally we were more strict on changing the version number
after failed votes, but we've since backed off. The reason for not being
as strict, if I recall, is that people can still download the failed
version while it's available with the signatures and put them up on some
web site and call them official and people wouldn't know because the
signatures are valid. So, what are we really gaining by changing the
version number?
-> richard
On 2/2/11 9:01, Guillaume Nodet wrote:
> Last, remember each PMC decides on its own rules to govern its project.
> So the fact Roy sent an email on Jackrabbit doesn't make it an
> official policy for the ASF (and the ASF itself doesn't care about
> such technical details).
>
> I'll re-roll those releases, but I'd like things to be agreed upon
> *and* documented at some point.
>
> On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet<gn...@gmail.com> wrote:
>> On Wed, Feb 2, 2011 at 14:18, Felix Meschberger<fm...@adobe.com> wrote:
>>> Hi,
>>>
>>> My vetoes (actually there is no veto in a release vote since this is a
>>> majority vote)
>> I know there's no vetoes in releases, but the goal is usually to
>> gather a consensus.
>> The fact you voted -1 puts a lot of pressure on me if I want to go to
>> the majority in order to have those released ;-)
>>
>>> are grounded on a message Roy Fielding once sent to the
>>> Jackrabbit list [1]:
>>>
>>>> The problem with doing all of our laundry in public is that the public
>>>> often download our unreleased packages even when we tell them not to.
>>>> For that reason, most Apache projects increment the patch-level number
>>>> each time a new package is produced (releases do not need to be
>>>> sequential).
>> I suppose that depends on the definition of "most". Over the dozen of
>> projects I'm involved at the ASF, this is the first time I see that.
>> Maybe for projects like httpd that was the case, but I don't expect
>> many people that aren't felix committers to have downloaded those
>> released in the last 48 hours, so I still stand by the fact that in
>> our case, people are very aware that the jars aren't official yet.
>>
>> Anyway, if that's us becoming an official Felix project policy, I'd
>> like that to be written somewhere. Oral tradition is not really good
>> for newcomers ;-)
>>
>>> Unfortunately I cannot readily find the written rule for this, but this
>>> makes perfect sense to me, which is why I would prefer to get a new
>>> version number. Which is also why I always choose a new version number
>>> for a release vote after I had to cancel a vote.
>>>
>>> Regards
>>> Felix
>>>
>>> [1] http://markmail.org/message/533ybky6pqwwc2is
>>>
>>> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
>>>> Over the past two years, I've been doing several releases in Felix and
>>>> i've re-rolled some with the same version without any problems.
>>>> I don't see any mention about not reusing the same number twice in the
>>>> release process:
>>>> http://felix.apache.org/site/release-management-nexus.html
>>>> What's the driver behing that ?
>>>>
>>>> Until those releases are published, poeple accessing those are fully
>>>> aware of waht they are, so I don't see that as a problem.
>>>>
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
Re: [DISCUSS] Re-trying releases
Posted by Guillaume Nodet <gn...@gmail.com>.
Last, remember each PMC decides on its own rules to govern its project.
So the fact Roy sent an email on Jackrabbit doesn't make it an
official policy for the ASF (and the ASF itself doesn't care about
such technical details).
I'll re-roll those releases, but I'd like things to be agreed upon
*and* documented at some point.
On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
> On Wed, Feb 2, 2011 at 14:18, Felix Meschberger <fm...@adobe.com> wrote:
>> Hi,
>>
>> My vetoes (actually there is no veto in a release vote since this is a
>> majority vote)
>
> I know there's no vetoes in releases, but the goal is usually to
> gather a consensus.
> The fact you voted -1 puts a lot of pressure on me if I want to go to
> the majority in order to have those released ;-)
>
>> are grounded on a message Roy Fielding once sent to the
>> Jackrabbit list [1]:
>>
>>> The problem with doing all of our laundry in public is that the public
>>> often download our unreleased packages even when we tell them not to.
>>> For that reason, most Apache projects increment the patch-level number
>>> each time a new package is produced (releases do not need to be
>>> sequential).
>
> I suppose that depends on the definition of "most". Over the dozen of
> projects I'm involved at the ASF, this is the first time I see that.
> Maybe for projects like httpd that was the case, but I don't expect
> many people that aren't felix committers to have downloaded those
> released in the last 48 hours, so I still stand by the fact that in
> our case, people are very aware that the jars aren't official yet.
>
> Anyway, if that's us becoming an official Felix project policy, I'd
> like that to be written somewhere. Oral tradition is not really good
> for newcomers ;-)
>
>>
>> Unfortunately I cannot readily find the written rule for this, but this
>> makes perfect sense to me, which is why I would prefer to get a new
>> version number. Which is also why I always choose a new version number
>> for a release vote after I had to cancel a vote.
>>
>> Regards
>> Felix
>>
>> [1] http://markmail.org/message/533ybky6pqwwc2is
>>
>> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
>>> Over the past two years, I've been doing several releases in Felix and
>>> i've re-rolled some with the same version without any problems.
>>> I don't see any mention about not reusing the same number twice in the
>>> release process:
>>> http://felix.apache.org/site/release-management-nexus.html
>>> What's the driver behing that ?
>>>
>>> Until those releases are published, poeple accessing those are fully
>>> aware of waht they are, so I don't see that as a problem.
>>>
>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Re-trying releases
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Feb 2, 2011 at 14:18, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> My vetoes (actually there is no veto in a release vote since this is a
> majority vote)
I know there's no vetoes in releases, but the goal is usually to
gather a consensus.
The fact you voted -1 puts a lot of pressure on me if I want to go to
the majority in order to have those released ;-)
> are grounded on a message Roy Fielding once sent to the
> Jackrabbit list [1]:
>
>> The problem with doing all of our laundry in public is that the public
>> often download our unreleased packages even when we tell them not to.
>> For that reason, most Apache projects increment the patch-level number
>> each time a new package is produced (releases do not need to be
>> sequential).
I suppose that depends on the definition of "most". Over the dozen of
projects I'm involved at the ASF, this is the first time I see that.
Maybe for projects like httpd that was the case, but I don't expect
many people that aren't felix committers to have downloaded those
released in the last 48 hours, so I still stand by the fact that in
our case, people are very aware that the jars aren't official yet.
Anyway, if that's us becoming an official Felix project policy, I'd
like that to be written somewhere. Oral tradition is not really good
for newcomers ;-)
>
> Unfortunately I cannot readily find the written rule for this, but this
> makes perfect sense to me, which is why I would prefer to get a new
> version number. Which is also why I always choose a new version number
> for a release vote after I had to cancel a vote.
>
> Regards
> Felix
>
> [1] http://markmail.org/message/533ybky6pqwwc2is
>
> Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
>> Over the past two years, I've been doing several releases in Felix and
>> i've re-rolled some with the same version without any problems.
>> I don't see any mention about not reusing the same number twice in the
>> release process:
>> http://felix.apache.org/site/release-management-nexus.html
>> What's the driver behing that ?
>>
>> Until those releases are published, poeple accessing those are fully
>> aware of waht they are, so I don't see that as a problem.
>>
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Re-trying releases
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
My vetoes (actually there is no veto in a release vote since this is a
majority vote) are grounded on a message Roy Fielding once sent to the
Jackrabbit list [1]:
> The problem with doing all of our laundry in public is that the public
> often download our unreleased packages even when we tell them not to.
> For that reason, most Apache projects increment the patch-level number
> each time a new package is produced (releases do not need to be
> sequential).
Unfortunately I cannot readily find the written rule for this, but this
makes perfect sense to me, which is why I would prefer to get a new
version number. Which is also why I always choose a new version number
for a release vote after I had to cancel a vote.
Regards
Felix
[1] http://markmail.org/message/533ybky6pqwwc2is
Am Mittwoch, den 02.02.2011, 11:16 +0000 schrieb Guillaume Nodet:
> Over the past two years, I've been doing several releases in Felix and
> i've re-rolled some with the same version without any problems.
> I don't see any mention about not reusing the same number twice in the
> release process:
> http://felix.apache.org/site/release-management-nexus.html
> What's the driver behing that ?
>
> Until those releases are published, poeple accessing those are fully
> aware of waht they are, so I don't see that as a problem.
>