commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Date Thu, 31 Mar 2011 10:33:27 GMT
On 31 March 2011 04:00, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 3/30/11 6:57 PM, sebb wrote:
>> On 31 March 2011 01:38, Phil Steitz <phil.steitz@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.steitz@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message