On 19 December 2014 at 10:36, Luc Maisonobe <l...@spaceroots.org> wrote: > 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.
It should not be necessary for reviewers to search through a jar file to find this information. Good idea to have it there, but it needs to be included in the e-mail as well. >> >> 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>" > AFAICT, this requires the reviewer to install Git (and understand how to use it) Whereas with the sample Git URL I mentioned, it's possible to download a zip of the tree. Much easier to use. > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
