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<gno...@gmail.com> >>>>>> wrote: >>>>>>> On Wed, Feb 2, 2011 at 14:18, Felix Meschberger<fmesc...@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 >>>>>>> >> >>
