No, I'd cut off my own hand with a blunt teaspoon before I did that. On Thu, May 30, 2013 at 3:20 PM, Chris Graham <[email protected]> wrote:
> No, not at all. > > We're talking about removing the latest tag whilst in the process of > voting. > > My reading of what you wrote, was that you were suggesting to > retroactively go back and remove tags that are not the latest release. > > Which I believe is against the apache rules. > > -Chris > > Sent from my iPhone > > On 30/05/2013, at 10:06 PM, Fred Cooke <[email protected]> wrote: > > > Point missed. You said: > > > > It's a huge change; as if you do not delete, you now have broken > 'releases' > >> in a SCM somwhere, and that is radically different to what is currently > >> there. > >> > > > > And my point was, it's no change at all, there are already broken > > "releases" (without the quotes) in an SCM somewhere. So it's no different > > at all, certainly not radically different. > > > > Fred. > > > > PS, Stephen, you were lucky! I only got a plate with some cookie crums > and > > an empty glass smelling of lagavulin :-p > > > > On Thu, May 30, 2013 at 1:58 PM, Chris Graham <[email protected]> > wrote: > > > >> No, by their own rules, if the vote passed, then it's 'valid' release. > >> > >> That fact that we have more than one release of anything means that we > >> sometimes get it wrong. > >> > >> -Chris > >> > >> > >> On Thu, May 30, 2013 at 8:38 PM, Fred Cooke <[email protected]> > wrote: > >> > >>> Are you saying that tags for 2.1 and 2.2.0 of Maven itself should be > >>> deleted because those versions are broken? A tag isn't a guarantee of > >>> correctness/non-brokenness, it's just a *permanent* record of what a > >>> particular version contained. The concept of immutability is pretty > core > >> to > >>> Maven (at least in my mind). When I first witnessed the deletion of > tags > >>> and re-spinning of versions some months ago it was the most disturbing > >>> thing that's happened to me since I found out that Santa Claus wasn't > >> real. > >>> This is (supposed to be) the pinnacle of release engineering, setting > an > >>> example for all to follow, and it's breaking its own rules. I was, > quite > >>> literally, very sad. This seems like an opportunity to fix the > situation. > >>> I'm baffled by some of the things being said, though. > >>> > >>> On Thu, May 30, 2013 at 12:26 PM, Chris Graham <[email protected]> > >>> wrote: > >>> > >>>> One more thing to consider: > >>>> > >>>> It's a huge change; as if you do not delete, you now have broken > >>> 'releases' > >>>> in a SCM somwhere, and that is radically different to what is > currently > >>>> there. > >>>> > >>>> I should be able to check anything out now from a tag, build it and > >> have > >>> it > >>>> work. > >>>> > >>>> If we allow broken tags, then we could be frustrating a lot of people. > >>>> > >>>> It's a huge change of process. > >>>> > >>>> And for me, I prefer not to introduce it. > >>>> > >>>> We also have maven's concept of immutability, which is a reason NOT to > >>>> allow the reuse of numbers; however, that does not appear to have been > >>> too > >>>> much of a problem up until now. > >>>> > >>>> -Chris > >>>> > >>>> > >>>> > >>>> > >>>> On Thu, May 30, 2013 at 7:55 PM, Stephen Connolly < > >>>> [email protected]> wrote: > >>>> > >>>>> On 30 May 2013 10:30, Chris Graham <[email protected]> wrote: > >>>>> > >>>>>> Thank you Stephen for taking the time to explain. > >>>>>> > >>>>>> To me, the key critical bits are: > >>>>>> > >>>>>> 1. The full normal tag is created, and deleted if failed. If the > >>>> release > >>>>>> process fails (as in release:prepare/release:perform) we often have > >>> to > >>>>>> delete the tag and manually re-run it anyway. > >>>>>> > >>>>> > >>>>> Well to my mind that is also part of the issue.... > >>>>> > >>>>> If we accept that failed tags get deleted, then we should respin > >>> reusing > >>>>> the same version number until we have a non-failed tag (irrespective > >> of > >>>> the > >>>>> reason for the failure) > >>>>> > >>>>> If we don't reuse version numbers, it should be ever, in which case > >> if > >>>>> release:prepare produces a tag that *cannot* complete release:perform > >>> (as > >>>>> opposed to just a failure for a single run of release:perform) then > >> we > >>>>> would not delete the tag and run release:prepare for the next version > >>>>> number. > >>>>> > >>>>> In that sense I don't see this as a critical bit... rather I see it > >> as > >>>> part > >>>>> of what should be covered by the vote. > >>>>> > >>>>> > >>>>>> 2. The copying process to get it in the wild is manual and post > >> vote. > >>>>>> > >>>>> > >>>>> Not quite true, the artifacts are in the wild... just in a staging > >>>>> repository from which they can be deleted. The copy to dist is a > >> legal > >>>>> requirement to ensure the legal protections that the ASF provides > >>> remain > >>>> in > >>>>> force (this is also why the PMC have binding votes, and why the PMC > >> has > >>>> to > >>>>> concern itself with annoying pesky things like ensuring that the > >>>> NOTICE.txt > >>>>> has correct content and that files have the correct license > >> headers... > >>> I > >>>>> may not, in the past, have fully appreciated the reasons for or the > >>> needs > >>>>> for these things... but since becoming a member of the ASF [with the > >>>> legal > >>>>> responsibilities that come with that] I have gained a different > >>>>> perspective). > >>>>> > >>>>> But there is always concern from people that they will end up with > >>> their > >>>>> local repository corrupted as a side-effect of testing. > >>>>> > >>>>> For instance, suppose there is a fix related to how some component > >>> works > >>>>> behind a proxy. That may well require you to add the staging > >> repository > >>>> to > >>>>> your corporate proxy repository (because the machines you want to > >> test > >>>>> from, and perhaps even the scenario you want to test, are required to > >>>> have > >>>>> a <mirrorOf>*</mirrorOf> in their settings.xml)... in such a case you > >>>> will > >>>>> end up with the situation that the test machines have downloaded the > >>>>> artifacts into their local repository cache *and* even with the > >>>> repository > >>>>> source validation that Maven 3.x brings to the table, you will need > >> to > >>>>> manually purge those artifacts from your local repository cache > >>> *because* > >>>>> the <mirrorOf>*</mirrorOf> will be forcing the source of those > >> release > >>>>> artifacts to be unchanged. > >>>>> > >>>>> Now one could argue that you shouldn't be adding the staging repo to > >>> your > >>>>> proxy in the first place, and instead you should create a special > >> proxy > >>>> on > >>>>> your repository manager that adds in the staging repo on top of the > >>>> normal > >>>>> proxy and update the settings.xml to use this new mirrorOf source... > >>> but > >>>>> that will force everything to be re-downloaded into the local cache > >>> *and* > >>>>> there are test circumstances where one might fear that such a change > >>>> could > >>>>> affect the validity of your testing. > >>>>> > >>>>> The above, to my mind, is the primary driver for never reusing > >> version > >>>>> numbers... whether it is worthy of the change is for all to decide... > >>>>> > >>>>> My current thinking is though: > >>>>> > >>>>> * if we allow deleting tags because the tag won't complete > >>>> release:perform, > >>>>> then we should re-use version numbers. > >>>>> > >>>>> * if we don't allow re-using version numbers, then we should not > >> allow > >>>>> deleting tags *just* because the tag won't complete release:perform. > >>>>> > >>>>> And I am considering whether I want to change my vote ;-) > >>>>> > >>>>> > >>>>>> Given that, I have no problem with respinning a release using the > >>> same > >>>>>> version, which is, essentially what we have been doing. > >>>>>> > >>>>>> This is very similar to what I do for the day job. But not the > >> same. > >>> In > >>>>> the > >>>>>> day job, we through away a release and just create a new one. > >>>>>> > >>>>>> Why the difference? > >>>>>> > >>>>>> Simple, the audience for the day job is limited, and the decision > >> to > >>>>>> release is driven by the tech lead and immediate. > >>>>>> > >>>>>> There is no voting process. > >>>>>> > >>>>>> In this OS world, we are talking about release X.Y.Z (or whatever) > >>> and, > >>>>>> personally, I remember X.Y.Z. I would quickly get confused if I had > >>> to > >>>>>> constantly remember that X.Y.Z is now X.Y.(Z+N). > >>>>>> > >>>>>> Additionally, the vote remains open for a period of time, and I > >> would > >>>> get > >>>>>> lost with the constantly changing numbers. Note, this is not the > >> same > >>>> as > >>>>>> saying anything about skipped public version numbers. > >>>>>> > >>>>>> For the same reason, I would recommend offering different > >> approaches > >>> to > >>>>>> core/plugins/whatever: let's not complicate things. > >>>>>> > >>>>>> So, to that end, > >>>>>> > >>>>>> -1 (ie respin) for all > >>>>>> > >>>>>> (non binding) > >>>>>> > >>>>>> -Chris > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Thu, May 30, 2013 at 5:11 PM, Stephen Connolly < > >>>>>> [email protected]> wrote: > >>>>>> > >>>>>>> On Thursday, 30 May 2013, Chris Graham wrote: > >>>>>>> > >>>>>>>> What do we currently do for plugins? > >>>>>>> > >>>>>>> What do we currently do for core? > >>>>>>>> Is there in difference in the approach taken? > >>>>>>> > >>>>>>> > >>>>>>> No difference. In each case we currently respin failed votes > >>> reusing > >>>>> the > >>>>>>> version number until we get an actual successful vote. > >>>>>>> > >>>>>>>> > >>>>>>>> We call for a vot for vX.Y.Z of <arbitrary plugin> (plugins's > >>>>> [recently > >>>>>>> at > >>>>>>>> least] do not appear to go throught he beta/RC phases). > >>>>>>> > >>>>>>> > >>>>>>> That is down to not really having new core plugins recently, and > >>> the > >>>>> size > >>>>>>> of changes being such that the release manager felt there was no > >>> need > >>>>> for > >>>>>>> an alpha/beta > >>>>>>> > >>>>>>> Because of the switch from sonatype aether to eclipse aether > >> *and* > >>>> the > >>>>>>> exposing of the aether API to plugins, for Maven 3.1.0 jumping > >>>> straight > >>>>>> to > >>>>>>> 3.1.0 was deemed too risky by the release manager, hence > >>>> 3.1.0-alpha-1. > >>>>>>> > >>>>>>> Personally, given the lack of review the 3.1.0-SNAPSHOTs were > >>>> getting, > >>>>>> this > >>>>>>> was probably a wise plan... However I think quite a few people > >> have > >>>> put > >>>>>>> their eyes on the code by now, so *if* I was the release manager, > >>> I'd > >>>>> be > >>>>>>> tempted to head straight for 3.1.0... Thankfully I am not release > >>>>> manager > >>>>>>> for this release, so not my problem ;-) > >>>>>>> > >>>>>>> (Note: the release manager is just whoever stands up and says "I > >>> want > >>>>> to > >>>>>>> cut a release of XYZ"... Can change with every release, or stay > >>>> mostly > >>>>>> the > >>>>>>> same. Eg Kristian has been release manager for Surefire by > >>>> consistently > >>>>>>> stepping up and cutting releases, but if any other committer > >> wanted > >>>> to > >>>>>> run > >>>>>>> a release they can step up at any time... It's actually something > >>> we > >>>>>>> encourage newer committers to do (usually starting with smaller > >>>> plugins > >>>>>>> though) so that they can get a feel for how our release process > >>> works > >>>>>>> (learn by doing)) > >>>>>>> > >>>>>>>> > >>>>>>>> Can someone please spell out a sequence of events (by time) as > >> to > >>>>> what > >>>>>>>> happens through the entire process? From prep to vote to ending > >>> up > >>>> in > >>>>>>>> central. > >>>>>>>> > >>>>>>>> Slightly simplified, and there are differences for components > >> vs > >>>>>> plugins > >>>>>>> vs core, but essential principle remains close to this > >>>>>>> > >>>>>>> 1. Run `mvn release:prepare release:perform` > >>>>>>> 2. Send the "[vote]" email > >>>>>>> 3. Wait 72h (or longer if not enough binding votes and the > >> release > >>>>>> manager > >>>>>>> thinks some more binding votes will turn up) > >>>>>>> 4. On nexus, promote the staging repo > >>>>>>> 5. Update JIRA versions > >>>>>>> 6. Update the component's site (and for plugins the table of > >> plugin > >>>>>>> versions) > >>>>>>> 7. Copy the artifacts to dist > >>>>>>> 8. Wait for "the sync" to central > >>>>>>> 9. Send "[ann]" email > >>>>>>> > >>>>>>> And the same sequnce, but for a failed vote, and it's revoting > >>> (we've > >>>>>> used > >>>>>>>> the same version no again, here, have we not?) > >>>>>>> > >>>>>>> > >>>>>>> After step 3, we currently delete the tag, go back to step 1. And > >>>>> release > >>>>>>> again reusing the same version number from the first time. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> -Chris > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Thu, May 30, 2013 at 6:11 AM, Fred Cooke < > >>> [email protected] > >>>>>>> <javascript:;>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -1 for actual releases: it would create more mess imo for > >> end > >>>>> users > >>>>>>> if > >>>>>>>>>> there's many bizarre jumps in numbering > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The thing with this argument is that it's very, very weak. > >> If a > >>>>>> missed > >>>>>>>>> version confuses a user, they're basically brain-dead. > >> Assuming > >>>>> your > >>>>>>>> users > >>>>>>>>> are brain dead is _always_ dangerous. Assuming the users or a > >>>>>>>> _development_ > >>>>>>>>> tool are brain-dead is that in and of itself IMO. > >>>>>>>>> > >>>>>>>>> A random example from central that I gave to Robert earlier: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > http://search.maven.org/#search|gav|1|g%3A%22antlr%22%20AND%20a%3A%22antlr%22 > >>>>>>>>> > >>>>>>>>> I don't know about the rest of you... but I'm not confused by > >>> the > >>>>>>> absence > >>>>>>>>> of 2.7.3 in any way shape or form. I'm additionally not > >>> confused > >>>> by > >>>>>> the > >>>>>>>>> absence of 2.7.8, 2.7.9, 2.7.10, etc, nor 2.8.* nor 2.9.* > >> It's > >>>>>>>> meaningless > >>>>>>>>> to me that they're absent. I use and test a version (usually > >>>>> latest) > >>>>>>> and > >>>>>>>>> verify it functions adequately for my needs, then I depend on > >>> it > >>>>> (dep > >>>>>>> or > >>>>>>>>> plugin equally) and that's it. If I find a flaw, or need to > >>> use a > >>>>> new > >>>>>>>>> feature, then I can go looking for the best version that is > >>>>>> compatible > >>>>>>>> with > >>>>>>>>> my setup, that contains it (again, likely latest, API change > >>> not > >>>>>>>>> withstanding). > >>>>>>>>> > >>>>>>>>> Being worried about developers being confused by a > >>> non-sequential > >>>>> set > >>>>>>> of > >>>>>>>>> binaries to choose from is bizarre at best. Developers, even > >>> the > >>>>> bad > >>>>>>>> ones, > >>>>>>>>> are generally a fairly intelligent bunch. > >>>>>>>>> > >>>>>>>>> This is not winamp! :-p (nor VLC) > >>>>>>>>> > >>>>>>>>> Fred. > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Sent from my phone > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
