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<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 >>>>>>>>> >>>> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
