incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <>
Subject Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Date Fri, 17 Jul 2015 07:40:04 GMT
Realizing I forgot the link to the release doc (WIP):

2015-07-17 9:31 GMT+02:00 Emmanuel Lécharny <>:
> 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
>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message