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
