Realizing I forgot the link to the release doc (WIP): http://groovy-lang.org/wiki/incubation-release-process.html
2015-07-17 9:31 GMT+02:00 Emmanuel Lécharny <elecha...@gmail.com>: > Le 17/07/15 09:21, Cédric Champeau a écrit : >>> Lets be clear, what I was referring to is this: the identified L&N issue >>> is a non-code change that has no implication to the stability of your >>> release whatsoever. Hence manually fixing it, re-spinning the RC and >>> calling a shortened (12-24h) vote doesn't seem to present a problem >> First of all, the fact of rolling back a release already takes time. >> There's much more involved than a couple of artifacts uploaded on >> dist.apache.org. We are very picky at quality, and a release is issued >> from a CI server, which automates all tasks that are subject to human >> errors. It involves creating a release branch, tagging, uploading >> Maven artifacts to Artifactory, uploading the distribution to Bintray, >> synchronizing to Maven Central, etc... What we did for the new Apache >> release process is cut this into small steps that introduce potential >> human errors. And basically, we have staging areas for the >> source/distribution artifacts (what you vote on), and staging area for >> the complete set of artifacts (Groovy produces more than 270 jar >> artifacts). Rolling back, as I said, implies several steps, including >> closing those staging repos, removing the tags, branches, ... And due >> to some restrictions of the Apache infrastructure, we have a complex >> setup (we need to push the tags on personal branches from GitHub, then >> push them to Apache Git, as explained in our release document [1]). >> >> So, rolling back a release is not cheap. And then, you have to release >> again. And releasing, for the same reasons, is far from being cheap. I >> am the first one really annoyed by this as the release manager, >> because as I explained when joining Apache, I spent numerous hours >> polishing the Groovy release process, and releasing was a single click >> button. I could release 2 branches of Groovy in a couple of hours. >> *That* was cheap. For this release, it took me several hours and a lot >> of manual steps are involved. I know most of you are used to release >> from your own computers. That simplifies things a little, but that's >> not a guarantee of quality, in the sense that human errors are >> possible: you could release from a local source tree which is not >> exactly what the source reference is (so produce a correct source zip >> but that would differ from what the real source is), you could have >> dependencies in your local Maven repo which wouldn't be found >> otherwise (caching problem), you could build on a non-approved JDK >> (our CI builds do it from JDKs which were approved to be bug-free by >> the team, in particular with invokedynamic...), ... We don't want to >> do that. >> >> In addition, fixing this L&N issue is not cheap either. First of all, >> we were not aware that the source and binary versions had to be >> different (and it seems that our mentors missed it for the first RC we >> tried). Second, we are still working on the issue, because we want to >> avoid being downvoted again, so it implies a lot of new sanity checks. >> Paul is doing that, but that's all on personal time of a distributed >> team, so no, we wouldn't have released in time. And there were already >> changes to the codebase after the rc was issued (development doesn't >> stop during voting), so either we would have to fork the RC branch, >> release from it and add new burden to our release process, or we would >> have to revote for everything including sources. >> >> Last but not least, I would also say that none of us was aware that a >> shortened vote period was possible. And since at Apache, everybody >> seem to have an opinion on everything, we would have taken the risk of >> being downvoted for not giving enough time to vote. That said, given >> that our vote on dev@ passed because we gave enough time to our >> voters. With 24h voting period we wwouldn't have had enough votes. >> Also, if we reissue a rc for the IPMC, I don't see why only the IPMC >> should vote. Otherwise it means that the artifacts that were voted on >> dev@ are different from those voted on general@. And that's a bad >> thing IMHO. >> >> To my mind, incubating is about learning how this works, and I think >> we're doing a reasonable job in that area. If you put the entry level >> too high, then you just discourage people to contribute. > > ALl of this makes perfect sense to me. > > Now, I'm a bit scared : why the hell can't we make it easier to cut a > release at Apache for this project ? I mean, the infrastructure should > not be a limitation here : we do have a CI, we most certainly can tune > it to fit Groovy. > > I suggest we discuss this matter instead of arguing about why this > release was not perfect (we all agreed on that already) The critical > point is that it should not take hours to cut a release nor to rollback > it. That would be a constructive discussion. > > I'd like to remember everyone that each project is quite able to define > the way they do things, as soon as they fits in the Apache process, > which is not that rigid. At this point, we may dedicate some time with > mentors, someone from infra and obviously the project's RM. If we don't > do that now we are painfully impairing the project... > > My 2cts. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
