On 19 December 2014 at 06:02, Luc Maisonobe <l...@spaceroots.org> wrote: > 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 ?
No. > 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? The VOTE thread needs to include the information. And it needs to be clear what artifacts people are voting on. This can be done without respinning the release. If I were RM, I would find it easier to keep track of the process if a new VOTE email were started. > 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. This is why the VOTE e-mail needs the SVN revision or Git hash. > Furthermore, git tags can be GPG signed, which I did here. > In which case, include the sig in the e-mail please. >> >> 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). Yes, the staging area is fairly useless for reviewing site changes that may need to be reverted. However I agree that site updates are not part of the release vote and can be corrected at a later date if necessary. > So to avoid this, I'll go back to unpakc a zip on people.apache.org next > time. Probably best. > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
