Le 19/12/2014 03:25, Gary Gregory a écrit : > On Thu, Dec 18, 2014 at 8:14 PM, sebb <seb...@gmail.com> wrote: >> >> If it's not done properly, why bother with a VOTE at all? >> > > I'm with Sebb here. Yes, our release process is a PITA, but what Sebb is > asking for is what I expect as well. If you want me to evaluate a RC and > VOTE, please make my life and that of all the other reviewers, easier, not > harder.
So do you want me to cancel the vote, redo all the process just because the *mail* did not include the SHA ? Or should I cancel the vote and just relaunch it from the exact same artifacts (and hence still and RC1) to make the tag retrieving process clearer? By the way MATH_3_4_RC1 is really a tag, its not a branch despite the command I suggested to retrieve it used the --branch option from git clone; this option accepts both tags and branches. But I agree, even tags in git can be deleted and recreated ... just like tags in svn which can also be changed despite policy is to not do it. So in reality, there is no less traceability here with a git tag than with a svn tag. Furthermore, git tags can be GPG signed, which I did here. > > Sometimes, I download the src zip and build, sometimes, I checkout the > tag... > > FWIW, it should take a few minutes to transfer a site. Zip it, transfer it, > unzip it. One file at a time is asking for problems IMO. Or are you saying > that it takes hours to transfer even as a Zip? I tried to use the existing staging area for the site, so was stuck to use svn, which does takes hours and in my case fails if the number of files is too large. In any case, even if I first upload a zip in my area on people.apache.org, I will have to use svn finally for updating the real site, and hence I will have to go through this. The real problem with my approach is that since the staging area is share, the site went live earlier than expected, so it is already on the main site by nown sorry for that. It is not really a problem since the site is already updated from time to time, as users asked on the list to have the development API online, so the current site was alread almost the final one (it was last published in mid-October, two months ago). So to avoid this, I'll go back to unpakc a zip on people.apache.org next time. best regards, Luc > > Gary > > >> >> On 19 December 2014 at 00:51, Emmanuel Bourg <ebo...@apache.org> wrote: >>> Le 19/12/2014 01:08, sebb a écrit : >>> >>>> The VOTE email should include all the information needed to validate a >> release. >>> >>> You are right but this is exactly the kind of hassle that makes release >>> management tedious and discourages people from publishing releases. At >>> some point a balance has to be found between the expectations, and I >>> think publishing new releases is more important than posting a VOTE mail >>> with an encyclopedic precision. >>> >>> IMHO Luc provided enough information to review the release properly. >>> >>> Emmanuel Bourg >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
