incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From C├ędric Champeau <cedric.champ...@gmail.com>
Subject Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Date Fri, 17 Jul 2015 07:21:09 GMT
>
> 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.

>
> I just don't understand why you didn't entertain that as an option. Personally
> I would've made myself available to cast my vote under very compressed
> schedule if you actually ASKED for it.
>
>> Not releasing would not have been serious, and we could have missed
>> the short timeframe we have given the vacations of the team.
>> It's also unfair because we took *very seriously* the comments for the
>> first attempt of the release, a few weeks ago, and fixed *all of them*
>> (and did even more than what you asked us to do).
>> So I think our community deserved that release more than having the
>> perfect L&N files (especially because as we said, the License file
>> contains more, but not less, than required), and as
>> Paul said, all jars produces *do* have them.
>>
>>> That's my strong expectation as well. If we're doing this whole
>>> mentoring thing -- lets do it right.
>>
>> I sincerely hope my position is understood this time.
>
> Then, perhaps, following up with the dot release once the current one
> is out, would be a way to go. Dot releases are cheap and easy and
> having a releases that is actually squeaky clean from the IP perspective
> is what Incubation is partially about.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message