> > 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-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
