Le 19/12/2014 13:51, Gary Gregory a écrit : > On Fri, Dec 19, 2014 at 1:02 AM, 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 ? 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? >> > > What I would do is reply to my original VOTE mail with the missing > information.
This is what I did. The missing information is both in this message <http://markmail.org/message/he5t4nwcenhdu4sa> and in this message <http://markmail.org/message/cue334v4yo6z7s2d>. > Since the artifacts have not changed, there is no need to > repeat the whole process. Calling a new VOTE thread is OK too, perhaps > cleaner, especially for archeologists. Well, the discussion is worth preserving too, and a new thread would delay the result 15 hours later. So I'll keep this vote thread open until a problem is found on the artifacts themselves. best regards, Luc > > Gary > > >> >> 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
