Hi Sebb, Le 19/12/2014 11:17, sebb a écrit : > 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.
Thanks, this is a relief for me. > >> 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. So to be clear, I repeat the hash here: The tag points to commit cf4a9d70c9ac24dd7196995390171150e4e56451. The release artifacts were created from a fresh release of this tag. This hash appears in the manifest entry on the jar (near the end of the file), in the Implementation-Build entry. > > If I were RM, I would find it easier to keep track of the process if a > new VOTE email were started. Sure. I have modified the instructions in our [math] release howto. I will copy this howto to the wiki as soon as I get write access on it. > >> 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. Git tag signatures are stored by git itself, they are not detached .asc files. I already included the command to check the signature in the first vote email. You have to run git tag -v MATH_3_4_RC1 The result should be something like object cf4a9d70c9ac24dd7196995390171150e4e56451 type commit tag MATH_3_4_RC1 tagger Luc Maisonobe <l...@apache.org> 1418934614 +0100 Creating Apache Commons Math v3.4 RC1 tag. gpg: Signature made Thu Dec 18 21:30:14 2014 CET using RSA key ID 02E9F65B gpg: Good signature from "Luc Maisonobe (CODE SIGNING KEY) <l...@apache.org>" gpg: aka "Luc Maisonobe <luc.maison...@c-s.fr>" gpg: aka "Luc Maisonobe <luc.maison...@free.fr>" gpg: aka "Luc Maisonobe <l...@orekit.org>" best regards, Luc > >>> >>> 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
