On 31 March 2011 04:00, Phil Steitz <phil.ste...@gmail.com> wrote: > On 3/30/11 6:57 PM, sebb wrote: >> On 31 March 2011 01:38, Phil Steitz <phil.ste...@gmail.com> wrote: >>> On 3/30/11 4:22 PM, Jochen Wiedmann wrote: >>>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >>>> >>>>> I disagree with this. The most important artifacts are the >>>>> zips/tars that go to dist/. These *are* the ASF release. Nexus >>>>> makes it *harder* IMO to maintain provenance of these artifacts. >>>> These artifacts are present in Nexus. Pulling them to a temporary >>>> directory is quite easy with wget. >>> And then you need to check the hashes and sigs again since you are >>> now working with downloaded copies of the files that we voted on. >> Huh? >> >> If we create a script to move the files directly from Nexus staging to >> dist/, surely there's no chance that the cp+rm will somehow mangle the >> files? > mv is no problem. wget via http means you get a copy with the > network between. That is what I was referring to. In that case, > just like we tell the users, the RM should check hashes and sigs to > make sure that what actually ends up in dist/ is identical to what > we voted on.
I was assuming that we would use scp to copy the files between staging and dist, not wget. But if wget can cause problems, I've not seen any, and I use wget to download all the files when voting. [I have seen problems with Fx downloads; sometimes it silently truncates files] >>> Seems much easier and more correct to me to just scp the files to >>> p.a.o., let people vote on them and *move* exactly those files to >>> /dist. >> Which is much what happens with Nexus now, apart from the dist/ move >> phase which is not yet automated. >> > So the nexus staging repo lives on p.a.o? Does not look like it > from the IPs, unless there is some aliasing going on. If dist/ is > itself mirrored on r.a.o, then mv is possible; otherwise the files > have to be copied across the network, rather than moved. That > requires a recheck of the hashes. Huh? How do mirrors survive then? > Phil >>>> At which point I can see no >>>> difference between your proposed solution and this one. And there's >>>> nothing to do for all the other files that live in Nexus (and must >>>> live, because Maven is just too important, whether we like it or not). >>> Sorry, I don't buy that. The tars and zips need to "live" in >>> /dist. The maven artifacts need to make their way to the maven >>> mirrors. Having a "staging" repo where we can inspect the maven >>> bits before they get pushed out is great (though I think our homes >>> on p.a.o are fine for this). Why can't we just push files directly >>> there using scp or Ant tasks and then "promote" them to the rsynch >>> repo using a little script including commands like those in step 3 >>> of http://commons.apache.org/releases/release.html? >>>>> I also don't see why we *must* rely on proprietary software to >>>>> manage replication. >>>> I'm mostly with you on that. I strongly opposed choosing Nexus in >>>> favour of Archiva for that very reason. But we have Nexus now and I >>>> wouldn't want to have Commons a swimmer against the rest of the Apache >>>> tide. >>> Based on Mark's response, I don't think we are the only ones :) >>> >>> Phil >>>> Jochen >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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
