Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Niall Pemberton <ni...@gmail.com>]

On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>  After another nightmare by an RM who has not cut a release in a
> while, I think we need to do something.  The documentation on the
> Commons web pages describes a process that works.  I suggest that we
> standardize on that process, adding some simple automation scripts
> that RMs can choose to use or not to use for the manual steps and
> stop fussing with Nexus or the maven release plugin.  I cut an RC
> last night in 25 minutes (about 15 of which were spent waiting for
> the [pool] tests to complete) and will likely spend about that same
> amount of time deploying the artifacts to dist/ and what remains of
> our simple, file-and-directory-based replication infrastructure to
> get maven artifacts pushed to the maven repos.  I do use a simple
> shell script to manage invoking the maven commands and copying files
> around to reduce the required time from, say an hour, to 25
> minutes.  The script is in svn.
>
> I prefer the "manual" approach for the following reasons:
>
> 1.  I know what it does.  Exactly, every time.  I know that exactly
> the binaries that we vote on get deployed to dist/ and exactly the
> committed tag is used to build everything.  The process includes
> local generation of artifacts that I can inspect and test locally
> and verify sigs.  I know at each step exactly what is being pushed
> where.
>
> 2.  I know that it works.  Every time.  No pom-tweaking,
> plugin-munging or other half-success management required.
>
> 3.  It has no commercial / proprietary dependencies.  The scripts
> are optional and are in any case, ASF-licensed, committed to svn.
>
> I know others have different opinions on this.  It could be we need
> to support both ways of cutting releases.

AIUI then the deployment to the maven repository is either by dropping
the artifacts manually in
http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
Nexus. I think once a component switches to Nexus, then the manual
process doesn't work.

Niall

>  I would ask, however,
> that those arguing for the "automagical" approach take a hard look
> at how many volunteer hours are being spent trying to get
> maven/nexus to be a release manager and how comparatively little
> time those of us who take the "manual" approach spend getting our
> releases built and deployed.  While I certainly can't claim to
> produce perfect artifacts (much less code :), I will also point out
> that the only major release quality problem that we have had
> recently was the inadvertent release of a [net] version while
> fiddling with the release plugin.  I don't at all buy the argument
> that the manual approach is "error-prone" as it allows more and
> better opportunities for inspection by the RM and community at each
> stage.




> Phil

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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Ralph Goers <ra...@dslextreme.com>]

On Mar 29, 2011, at 8:08 AM, sebb wrote:

>> 
> 
> Yes, that is true.
> 
> Also, had the [net] release been using Nexus, it would have required 2
> additional manual stages to close and then release the Maven
> artifacts.
> It is impossible to accidentally release Maven artifacts using Maven
> command-line when using a staging manager such as Nexus.
> 
> But I agree that using manual processes up to that point is better
> than trying to use the Maven release plugin.
> 

As you well know, I've been working on releasing vfs for what seems like forever. The build using the release plugin took quite a bit of work to get going but now that it works there is no way I'd switch to something more manual. The only problem I have at the moment is that I'm waiting for the SCM plugin vote to pass so I can push out a new release of the release plugin.  That is so I can remove the release notes from svn after the tag is cut.  Once I have that I will be a happy camper.

Ralph

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Niall Pemberton <ni...@gmail.com>]

On Tue, Mar 29, 2011 at 10:23 PM, sebb <se...@gmail.com> wrote:
> On 29 March 2011 20:56, Niall Pemberton <ni...@gmail.com> wrote:
>> On Tue, Mar 29, 2011 at 8:08 PM, sebb <se...@gmail.com> wrote:
>>> On 29 March 2011 18:33, Niall Pemberton <ni...@gmail.com> wrote:
>>>> On Tue, Mar 29, 2011 at 5:18 PM, sebb <se...@gmail.com> wrote:
>>>>> On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
>>>>>> On 3/29/11 8:33 AM, sebb wrote:
>>>>>>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>>>>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>>>>>>  After another nightmare by an RM who has not cut a release in a
>>>>>>>>>>> while, I think we need to do something.  The documentation on the
>>>>>>>>>>> Commons web pages describes a process that works.  I suggest that we
>>>>>>>>>>> standardize on that process, adding some simple automation scripts
>>>>>>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>>>>>>> stop fussing with Nexus or the maven release plugin.  I cut an RC
>>>>>>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>>>>>>
>>>>>>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>>>>>>> get maven artifacts pushed to the maven repos.  I do use a simple
>>>>>>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>>>>>>> minutes.  The script is in svn.
>>>>>>>>>>>
>>>>>>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>>>>>>
>>>>>>>>>>> 1.  I know what it does.  Exactly, every time.  I know that exactly
>>>>>>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>>>>>>> committed tag is used to build everything.  The process includes
>>>>>>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>>>>>>> and verify sigs.  I know at each step exactly what is being pushed
>>>>>>>>>>> where.
>>>>>>>>>>>
>>>>>>>>>>> 2.  I know that it works.  Every time.  No pom-tweaking,
>>>>>>>>>>> plugin-munging or other half-success management required.
>>>>>>>>>>>
>>>>>>>>>>> 3.  It has no commercial / proprietary dependencies.  The scripts
>>>>>>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>>>>>>
>>>>>>>>>>> I know others have different opinions on this.  It could be we need
>>>>>>>>>>> to support both ways of cutting releases.
>>>>>>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>>>>>>> the artifacts manually in
>>>>>>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>>>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>>>>>>> process doesn't work.
>>>>>>>>> Yes, that is true.
>>>>>>>>>
>>>>>>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>>>>>>> additional manual stages to close and then release the Maven
>>>>>>>>> artifacts.
>>>>>>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>>>>>>> command-line when using a staging manager such as Nexus.
>>>>>>>>>
>>>>>>>>> But I agree that using manual processes up to that point is better
>>>>>>>>> than trying to use the Maven release plugin.
>>>>>>>> My assumption is that the Nexus stuff is supposed to work and make
>>>>>>>> life easier.  If it doesn't, I suppose we shouldn't use it.  Is it a
>>>>>>>> training issue, such that none of us simply knows exactly what it is
>>>>>>>> we ought to expect the process to do, and how it will do it?  This
>>>>>>>> type of thing is my chief complaint about Maven in general:  it's hard
>>>>>>>> to understand what's going on once you get a level or two of parent
>>>>>>>> POMs in there.  If it's just a matter of "we haven't discovered the
>>>>>>>> precise incantations that make the release plugin + Nexus instance do
>>>>>>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>>>>>>> walking one of us (who solemnly vows to document the entire experience
>>>>>>>> in full detail) through the entire lifecycle.
>>>>>>> Nexus is effectively a proxy, and has little bearing on how Maven
>>>>>>> deploy or release work.
>>>>>>> The artifacts end up in Nexus rather than in a directory that is
>>>>>>> auto-synched to Maven Central.
>>>>>>>
>>>>>>> This makes it easy to review the actual artifacts that will be
>>>>>>> deployed, as well as ensuring that artifacts cannot be accidentally
>>>>>>> deployed.
>>>>>
>>>>> Sorry, I was referring to the Maven artifacts, which is what went
>>>>> wrong with Net.
>>>>>
>>>>>> 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.
>>>>>
>>>>> AIUI the ASF release is the *source*, which is normally also released to Maven.
>>>>
>>>> IMO I don't quite agree with what either you or Phil said. The release
>>>> is whatever artefacts that we put out there for users to download. ASF
>>>> requires that we do a source release and anything else is a
>>>> convenience - but those other things are part of the release.
>>>
>>> Yes, I agree they are part of what we in Commons consider a release,
>>> but AIUI that is not the strict ASF position.
>>
>> No, thats what the ASF considers
>>
>>> My point was that it was not only the dist/ artifacts that matter.
>>
>> No, all parts matter.
>>
>> See http://www.apache.org/dev/release.html#what
>
> A while ago on a different project I complained that some binary
> packages were not part of the vote, and I was firmly told that it was
> only source that mattered.

We are required to release source and people often say the binaries
are only a "convenience" or that the "real" release is the source.
While those things are true, the mistake is then to say that anything
other than the source is not the release. It seems like a logical step
but its not.

The PMC is responsible for what this project *distributes* to people
as releases. Just because its a *binary* convenience artefact doesn't
mean that it isn't subject to the ASF's release policies. Take the
scenario, for example, where something was included in a binary
artefact that we didn't have the rights to distribute - that is why
those artefacts need to only be distributed as a release with the
approval of the PMC.

> When I re-read the documentation on the ASF site at the time, it did
> appear that such an interpretation was possible.

I don't know about that - but whats there now on the "Releases" page
is very clear and IMO makes that interpretation impossible.

> I may be able to find the e-mail thread, but it will take a while.

I don't think there is any point - why would that hold any weight over
what is on the ASF website, very clearly spelled out:

http://www.apache.org/dev/release.html

Niall

> I'm not saying that I think binary artifacts should not be included in
> release votes - just the opposite - but I was told otherwise.
>
>> Niall
>>
>>>>
>>>>> We don't have to use Nexus for non-Maven artifacts.
>>>>>
>>>>> IIRC, previously there was little or no visibility of what Maven
>>>>> artifacts would be released, and they were not always voted on.
>>>>
>>>> Rubbish. You make it sound like we only started checking maven
>>>> artifacts since Nexus.
>>>
>>> That was not my intention.
>>>
>>> I thought I had seen several votes where the Maven artifacts that were
>>> eventually released were not the exact ones voted on, because the
>>> release process that was used forced the RM to rebuild the jars in
>>> order to deploy them.
>>>
>>> But maybe I'm thinking of a different project.
>>>
>>> ==
>>>
>>> Nexus makes it easier to release Maven artifacts, as there is no need
>>> to mess with the maven-metadata.xml file [1]
>>>
>>> [1] http://commons.apache.org/releases/release.html#a3_Deploy_Maven_Artifacts
>>>
>>> ---------------------------------------------------------------------
>>> 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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb <se...@gmail.com>]

On 29 March 2011 20:56, Niall Pemberton <ni...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 8:08 PM, sebb <se...@gmail.com> wrote:
>> On 29 March 2011 18:33, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Tue, Mar 29, 2011 at 5:18 PM, sebb <se...@gmail.com> wrote:
>>>> On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
>>>>> On 3/29/11 8:33 AM, sebb wrote:
>>>>>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>>>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>>>>>  After another nightmare by an RM who has not cut a release in a
>>>>>>>>>> while, I think we need to do something.  The documentation on the
>>>>>>>>>> Commons web pages describes a process that works.  I suggest that we
>>>>>>>>>> standardize on that process, adding some simple automation scripts
>>>>>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>>>>>> stop fussing with Nexus or the maven release plugin.  I cut an RC
>>>>>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>>>>>
>>>>>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>>>>>> get maven artifacts pushed to the maven repos.  I do use a simple
>>>>>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>>>>>> minutes.  The script is in svn.
>>>>>>>>>>
>>>>>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>>>>>
>>>>>>>>>> 1.  I know what it does.  Exactly, every time.  I know that exactly
>>>>>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>>>>>> committed tag is used to build everything.  The process includes
>>>>>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>>>>>> and verify sigs.  I know at each step exactly what is being pushed
>>>>>>>>>> where.
>>>>>>>>>>
>>>>>>>>>> 2.  I know that it works.  Every time.  No pom-tweaking,
>>>>>>>>>> plugin-munging or other half-success management required.
>>>>>>>>>>
>>>>>>>>>> 3.  It has no commercial / proprietary dependencies.  The scripts
>>>>>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>>>>>
>>>>>>>>>> I know others have different opinions on this.  It could be we need
>>>>>>>>>> to support both ways of cutting releases.
>>>>>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>>>>>> the artifacts manually in
>>>>>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>>>>>> process doesn't work.
>>>>>>>> Yes, that is true.
>>>>>>>>
>>>>>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>>>>>> additional manual stages to close and then release the Maven
>>>>>>>> artifacts.
>>>>>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>>>>>> command-line when using a staging manager such as Nexus.
>>>>>>>>
>>>>>>>> But I agree that using manual processes up to that point is better
>>>>>>>> than trying to use the Maven release plugin.
>>>>>>> My assumption is that the Nexus stuff is supposed to work and make
>>>>>>> life easier.  If it doesn't, I suppose we shouldn't use it.  Is it a
>>>>>>> training issue, such that none of us simply knows exactly what it is
>>>>>>> we ought to expect the process to do, and how it will do it?  This
>>>>>>> type of thing is my chief complaint about Maven in general:  it's hard
>>>>>>> to understand what's going on once you get a level or two of parent
>>>>>>> POMs in there.  If it's just a matter of "we haven't discovered the
>>>>>>> precise incantations that make the release plugin + Nexus instance do
>>>>>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>>>>>> walking one of us (who solemnly vows to document the entire experience
>>>>>>> in full detail) through the entire lifecycle.
>>>>>> Nexus is effectively a proxy, and has little bearing on how Maven
>>>>>> deploy or release work.
>>>>>> The artifacts end up in Nexus rather than in a directory that is
>>>>>> auto-synched to Maven Central.
>>>>>>
>>>>>> This makes it easy to review the actual artifacts that will be
>>>>>> deployed, as well as ensuring that artifacts cannot be accidentally
>>>>>> deployed.
>>>>
>>>> Sorry, I was referring to the Maven artifacts, which is what went
>>>> wrong with Net.
>>>>
>>>>> 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.
>>>>
>>>> AIUI the ASF release is the *source*, which is normally also released to Maven.
>>>
>>> IMO I don't quite agree with what either you or Phil said. The release
>>> is whatever artefacts that we put out there for users to download. ASF
>>> requires that we do a source release and anything else is a
>>> convenience - but those other things are part of the release.
>>
>> Yes, I agree they are part of what we in Commons consider a release,
>> but AIUI that is not the strict ASF position.
>
> No, thats what the ASF considers
>
>> My point was that it was not only the dist/ artifacts that matter.
>
> No, all parts matter.
>
> See http://www.apache.org/dev/release.html#what

A while ago on a different project I complained that some binary
packages were not part of the vote, and I was firmly told that it was
only source that mattered.
When I re-read the documentation on the ASF site at the time, it did
appear that such an interpretation was possible.

I may be able to find the e-mail thread, but it will take a while.

I'm not saying that I think binary artifacts should not be included in
release votes - just the opposite - but I was told otherwise.

> Niall
>
>>>
>>>> We don't have to use Nexus for non-Maven artifacts.
>>>>
>>>> IIRC, previously there was little or no visibility of what Maven
>>>> artifacts would be released, and they were not always voted on.
>>>
>>> Rubbish. You make it sound like we only started checking maven
>>> artifacts since Nexus.
>>
>> That was not my intention.
>>
>> I thought I had seen several votes where the Maven artifacts that were
>> eventually released were not the exact ones voted on, because the
>> release process that was used forced the RM to rebuild the jars in
>> order to deploy them.
>>
>> But maybe I'm thinking of a different project.
>>
>> ==
>>
>> Nexus makes it easier to release Maven artifacts, as there is no need
>> to mess with the maven-metadata.xml file [1]
>>
>> [1] http://commons.apache.org/releases/release.html#a3_Deploy_Maven_Artifacts
>>
>> ---------------------------------------------------------------------
>> 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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Niall Pemberton <ni...@gmail.com>]

On Tue, Mar 29, 2011 at 8:08 PM, sebb <se...@gmail.com> wrote:
> On 29 March 2011 18:33, Niall Pemberton <ni...@gmail.com> wrote:
>> On Tue, Mar 29, 2011 at 5:18 PM, sebb <se...@gmail.com> wrote:
>>> On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 3/29/11 8:33 AM, sebb wrote:
>>>>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>>>>  After another nightmare by an RM who has not cut a release in a
>>>>>>>>> while, I think we need to do something.  The documentation on the
>>>>>>>>> Commons web pages describes a process that works.  I suggest that we
>>>>>>>>> standardize on that process, adding some simple automation scripts
>>>>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>>>>> stop fussing with Nexus or the maven release plugin.  I cut an RC
>>>>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>>>>
>>>>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>>>>> get maven artifacts pushed to the maven repos.  I do use a simple
>>>>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>>>>> minutes.  The script is in svn.
>>>>>>>>>
>>>>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>>>>
>>>>>>>>> 1.  I know what it does.  Exactly, every time.  I know that exactly
>>>>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>>>>> committed tag is used to build everything.  The process includes
>>>>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>>>>> and verify sigs.  I know at each step exactly what is being pushed
>>>>>>>>> where.
>>>>>>>>>
>>>>>>>>> 2.  I know that it works.  Every time.  No pom-tweaking,
>>>>>>>>> plugin-munging or other half-success management required.
>>>>>>>>>
>>>>>>>>> 3.  It has no commercial / proprietary dependencies.  The scripts
>>>>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>>>>
>>>>>>>>> I know others have different opinions on this.  It could be we need
>>>>>>>>> to support both ways of cutting releases.
>>>>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>>>>> the artifacts manually in
>>>>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>>>>> process doesn't work.
>>>>>>> Yes, that is true.
>>>>>>>
>>>>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>>>>> additional manual stages to close and then release the Maven
>>>>>>> artifacts.
>>>>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>>>>> command-line when using a staging manager such as Nexus.
>>>>>>>
>>>>>>> But I agree that using manual processes up to that point is better
>>>>>>> than trying to use the Maven release plugin.
>>>>>> My assumption is that the Nexus stuff is supposed to work and make
>>>>>> life easier.  If it doesn't, I suppose we shouldn't use it.  Is it a
>>>>>> training issue, such that none of us simply knows exactly what it is
>>>>>> we ought to expect the process to do, and how it will do it?  This
>>>>>> type of thing is my chief complaint about Maven in general:  it's hard
>>>>>> to understand what's going on once you get a level or two of parent
>>>>>> POMs in there.  If it's just a matter of "we haven't discovered the
>>>>>> precise incantations that make the release plugin + Nexus instance do
>>>>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>>>>> walking one of us (who solemnly vows to document the entire experience
>>>>>> in full detail) through the entire lifecycle.
>>>>> Nexus is effectively a proxy, and has little bearing on how Maven
>>>>> deploy or release work.
>>>>> The artifacts end up in Nexus rather than in a directory that is
>>>>> auto-synched to Maven Central.
>>>>>
>>>>> This makes it easy to review the actual artifacts that will be
>>>>> deployed, as well as ensuring that artifacts cannot be accidentally
>>>>> deployed.
>>>
>>> Sorry, I was referring to the Maven artifacts, which is what went
>>> wrong with Net.
>>>
>>>> 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.
>>>
>>> AIUI the ASF release is the *source*, which is normally also released to Maven.
>>
>> IMO I don't quite agree with what either you or Phil said. The release
>> is whatever artefacts that we put out there for users to download. ASF
>> requires that we do a source release and anything else is a
>> convenience - but those other things are part of the release.
>
> Yes, I agree they are part of what we in Commons consider a release,
> but AIUI that is not the strict ASF position.

No, thats what the ASF considers

> My point was that it was not only the dist/ artifacts that matter.

No, all parts matter.

See http://www.apache.org/dev/release.html#what

Niall

>>
>>> We don't have to use Nexus for non-Maven artifacts.
>>>
>>> IIRC, previously there was little or no visibility of what Maven
>>> artifacts would be released, and they were not always voted on.
>>
>> Rubbish. You make it sound like we only started checking maven
>> artifacts since Nexus.
>
> That was not my intention.
>
> I thought I had seen several votes where the Maven artifacts that were
> eventually released were not the exact ones voted on, because the
> release process that was used forced the RM to rebuild the jars in
> order to deploy them.
>
> But maybe I'm thinking of a different project.
>
> ==
>
> Nexus makes it easier to release Maven artifacts, as there is no need
> to mess with the maven-metadata.xml file [1]
>
> [1] http://commons.apache.org/releases/release.html#a3_Deploy_Maven_Artifacts
>
> ---------------------------------------------------------------------
> 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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb <se...@gmail.com>]

On 29 March 2011 18:33, Niall Pemberton <ni...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 5:18 PM, sebb <se...@gmail.com> wrote:
>> On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
>>> On 3/29/11 8:33 AM, sebb wrote:
>>>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>>>  After another nightmare by an RM who has not cut a release in a
>>>>>>>> while, I think we need to do something.  The documentation on the
>>>>>>>> Commons web pages describes a process that works.  I suggest that we
>>>>>>>> standardize on that process, adding some simple automation scripts
>>>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>>>> stop fussing with Nexus or the maven release plugin.  I cut an RC
>>>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>>>
>>>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>>>> get maven artifacts pushed to the maven repos.  I do use a simple
>>>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>>>> minutes.  The script is in svn.
>>>>>>>>
>>>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>>>
>>>>>>>> 1.  I know what it does.  Exactly, every time.  I know that exactly
>>>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>>>> committed tag is used to build everything.  The process includes
>>>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>>>> and verify sigs.  I know at each step exactly what is being pushed
>>>>>>>> where.
>>>>>>>>
>>>>>>>> 2.  I know that it works.  Every time.  No pom-tweaking,
>>>>>>>> plugin-munging or other half-success management required.
>>>>>>>>
>>>>>>>> 3.  It has no commercial / proprietary dependencies.  The scripts
>>>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>>>
>>>>>>>> I know others have different opinions on this.  It could be we need
>>>>>>>> to support both ways of cutting releases.
>>>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>>>> the artifacts manually in
>>>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>>>> process doesn't work.
>>>>>> Yes, that is true.
>>>>>>
>>>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>>>> additional manual stages to close and then release the Maven
>>>>>> artifacts.
>>>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>>>> command-line when using a staging manager such as Nexus.
>>>>>>
>>>>>> But I agree that using manual processes up to that point is better
>>>>>> than trying to use the Maven release plugin.
>>>>> My assumption is that the Nexus stuff is supposed to work and make
>>>>> life easier.  If it doesn't, I suppose we shouldn't use it.  Is it a
>>>>> training issue, such that none of us simply knows exactly what it is
>>>>> we ought to expect the process to do, and how it will do it?  This
>>>>> type of thing is my chief complaint about Maven in general:  it's hard
>>>>> to understand what's going on once you get a level or two of parent
>>>>> POMs in there.  If it's just a matter of "we haven't discovered the
>>>>> precise incantations that make the release plugin + Nexus instance do
>>>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>>>> walking one of us (who solemnly vows to document the entire experience
>>>>> in full detail) through the entire lifecycle.
>>>> Nexus is effectively a proxy, and has little bearing on how Maven
>>>> deploy or release work.
>>>> The artifacts end up in Nexus rather than in a directory that is
>>>> auto-synched to Maven Central.
>>>>
>>>> This makes it easy to review the actual artifacts that will be
>>>> deployed, as well as ensuring that artifacts cannot be accidentally
>>>> deployed.
>>
>> Sorry, I was referring to the Maven artifacts, which is what went
>> wrong with Net.
>>
>>> 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.
>>
>> AIUI the ASF release is the *source*, which is normally also released to Maven.
>
> IMO I don't quite agree with what either you or Phil said. The release
> is whatever artefacts that we put out there for users to download. ASF
> requires that we do a source release and anything else is a
> convenience - but those other things are part of the release.

Yes, I agree they are part of what we in Commons consider a release,
but AIUI that is not the strict ASF position.

My point was that it was not only the dist/ artifacts that matter.

>
>> We don't have to use Nexus for non-Maven artifacts.
>>
>> IIRC, previously there was little or no visibility of what Maven
>> artifacts would be released, and they were not always voted on.
>
> Rubbish. You make it sound like we only started checking maven
> artifacts since Nexus.

That was not my intention.

I thought I had seen several votes where the Maven artifacts that were
eventually released were not the exact ones voted on, because the
release process that was used forced the RM to rebuild the jars in
order to deploy them.

But maybe I'm thinking of a different project.

==

Nexus makes it easier to release Maven artifacts, as there is no need
to mess with the maven-metadata.xml file [1]

[1] http://commons.apache.org/releases/release.html#a3_Deploy_Maven_Artifacts

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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Niall Pemberton <ni...@gmail.com>]

On Tue, Mar 29, 2011 at 5:18 PM, sebb <se...@gmail.com> wrote:
> On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
>> On 3/29/11 8:33 AM, sebb wrote:
>>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>>  After another nightmare by an RM who has not cut a release in a
>>>>>>> while, I think we need to do something.  The documentation on the
>>>>>>> Commons web pages describes a process that works.  I suggest that we
>>>>>>> standardize on that process, adding some simple automation scripts
>>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>>> stop fussing with Nexus or the maven release plugin.  I cut an RC
>>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>>
>>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>>> get maven artifacts pushed to the maven repos.  I do use a simple
>>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>>> minutes.  The script is in svn.
>>>>>>>
>>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>>
>>>>>>> 1.  I know what it does.  Exactly, every time.  I know that exactly
>>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>>> committed tag is used to build everything.  The process includes
>>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>>> and verify sigs.  I know at each step exactly what is being pushed
>>>>>>> where.
>>>>>>>
>>>>>>> 2.  I know that it works.  Every time.  No pom-tweaking,
>>>>>>> plugin-munging or other half-success management required.
>>>>>>>
>>>>>>> 3.  It has no commercial / proprietary dependencies.  The scripts
>>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>>
>>>>>>> I know others have different opinions on this.  It could be we need
>>>>>>> to support both ways of cutting releases.
>>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>>> the artifacts manually in
>>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>>> process doesn't work.
>>>>> Yes, that is true.
>>>>>
>>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>>> additional manual stages to close and then release the Maven
>>>>> artifacts.
>>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>>> command-line when using a staging manager such as Nexus.
>>>>>
>>>>> But I agree that using manual processes up to that point is better
>>>>> than trying to use the Maven release plugin.
>>>> My assumption is that the Nexus stuff is supposed to work and make
>>>> life easier.  If it doesn't, I suppose we shouldn't use it.  Is it a
>>>> training issue, such that none of us simply knows exactly what it is
>>>> we ought to expect the process to do, and how it will do it?  This
>>>> type of thing is my chief complaint about Maven in general:  it's hard
>>>> to understand what's going on once you get a level or two of parent
>>>> POMs in there.  If it's just a matter of "we haven't discovered the
>>>> precise incantations that make the release plugin + Nexus instance do
>>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>>> walking one of us (who solemnly vows to document the entire experience
>>>> in full detail) through the entire lifecycle.
>>> Nexus is effectively a proxy, and has little bearing on how Maven
>>> deploy or release work.
>>> The artifacts end up in Nexus rather than in a directory that is
>>> auto-synched to Maven Central.
>>>
>>> This makes it easy to review the actual artifacts that will be
>>> deployed, as well as ensuring that artifacts cannot be accidentally
>>> deployed.
>
> Sorry, I was referring to the Maven artifacts, which is what went
> wrong with Net.
>
>> 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.
>
> AIUI the ASF release is the *source*, which is normally also released to Maven.

IMO I don't quite agree with what either you or Phil said. The release
is whatever artefacts that we put out there for users to download. ASF
requires that we do a source release and anything else is a
convenience - but those other things are part of the release.


> We don't have to use Nexus for non-Maven artifacts.
>
> IIRC, previously there was little or no visibility of what Maven
> artifacts would be released, and they were not always voted on.

Rubbish. You make it sound like we only started checking maven
artifacts since Nexus.

Niall

>> I also don't see why we *must* rely on proprietary software to
>> manage replication.  We have been replicating actual release
>> artifacts to hundreds - maybe thousands, by now - of Apache mirrors
>> for 10+ years now using rsynch.  I don't buy the argument that we
>> need to control access better to ibiblio-rsynch, since the same
>> applies to dist/ which is vastly more important and we trust RMs to
>> manage carefully.
>
> Note that accidental dist releases can easily be removed by us (and
> they will automatically disappear from mirrors).
>
> Removing Maven releases is much harder, and is not in our direct control.
>
> I don't really care whether we use Ant or Maven or whatever.
> However, I do care that any releases are subject to proper voting
> controls, and by that I mean we should vote on all release artifacts.
>
> Nexus seems to me to be a useful part of that process.
> Without it there have been some errors, not only Net, but also
> commons-daemon:commons-daemon:1.0.3 was somehow released with groupId
> org.apache.commons, presumably because it was added to the wrong
> directory on people. There may be other examples.
>
>> Phil
>>> Nexus release process is described here:
>>>
>>> http://www.apache.org/dev/publishing-maven-artifacts.html
>>>
>>>> Matt
>>>>
>>>>>> Niall
>>>>>>
>>>>>>>  I would ask, however,
>>>>>>> that those arguing for the "automagical" approach take a hard look
>>>>>>> at how many volunteer hours are being spent trying to get
>>>>>>> maven/nexus to be a release manager and how comparatively little
>>>>>>> time those of us who take the "manual" approach spend getting our
>>>>>>> releases built and deployed.  While I certainly can't claim to
>>>>>>> produce perfect artifacts (much less code :), I will also point out
>>>>>>> that the only major release quality problem that we have had
>>>>>>> recently was the inadvertent release of a [net] version while
>>>>>>> fiddling with the release plugin.  I don't at all buy the argument
>>>>>>> that the manual approach is "error-prone" as it allows more and
>>>>>>> better opportunities for inspection by the RM and community at each
>>>>>>> stage.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Phil
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb <se...@gmail.com>]

On 29 March 2011 16:52, Phil Steitz <ph...@gmail.com> wrote:
> On 3/29/11 8:33 AM, sebb wrote:
>> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>  After another nightmare by an RM who has not cut a release in a
>>>>>> while, I think we need to do something.  The documentation on the
>>>>>> Commons web pages describes a process that works.  I suggest that we
>>>>>> standardize on that process, adding some simple automation scripts
>>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>>> stop fussing with Nexus or the maven release plugin.  I cut an RC
>>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>>
>>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>>> get maven artifacts pushed to the maven repos.  I do use a simple
>>>>>> shell script to manage invoking the maven commands and copying files
>>>>>> around to reduce the required time from, say an hour, to 25
>>>>>> minutes.  The script is in svn.
>>>>>>
>>>>>> I prefer the "manual" approach for the following reasons:
>>>>>>
>>>>>> 1.  I know what it does.  Exactly, every time.  I know that exactly
>>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>>> committed tag is used to build everything.  The process includes
>>>>>> local generation of artifacts that I can inspect and test locally
>>>>>> and verify sigs.  I know at each step exactly what is being pushed
>>>>>> where.
>>>>>>
>>>>>> 2.  I know that it works.  Every time.  No pom-tweaking,
>>>>>> plugin-munging or other half-success management required.
>>>>>>
>>>>>> 3.  It has no commercial / proprietary dependencies.  The scripts
>>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>>
>>>>>> I know others have different opinions on this.  It could be we need
>>>>>> to support both ways of cutting releases.
>>>>> AIUI then the deployment to the maven repository is either by dropping
>>>>> the artifacts manually in
>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>>> process doesn't work.
>>>> Yes, that is true.
>>>>
>>>> Also, had the [net] release been using Nexus, it would have required 2
>>>> additional manual stages to close and then release the Maven
>>>> artifacts.
>>>> It is impossible to accidentally release Maven artifacts using Maven
>>>> command-line when using a staging manager such as Nexus.
>>>>
>>>> But I agree that using manual processes up to that point is better
>>>> than trying to use the Maven release plugin.
>>> My assumption is that the Nexus stuff is supposed to work and make
>>> life easier.  If it doesn't, I suppose we shouldn't use it.  Is it a
>>> training issue, such that none of us simply knows exactly what it is
>>> we ought to expect the process to do, and how it will do it?  This
>>> type of thing is my chief complaint about Maven in general:  it's hard
>>> to understand what's going on once you get a level or two of parent
>>> POMs in there.  If it's just a matter of "we haven't discovered the
>>> precise incantations that make the release plugin + Nexus instance do
>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>> walking one of us (who solemnly vows to document the entire experience
>>> in full detail) through the entire lifecycle.
>> Nexus is effectively a proxy, and has little bearing on how Maven
>> deploy or release work.
>> The artifacts end up in Nexus rather than in a directory that is
>> auto-synched to Maven Central.
>>
>> This makes it easy to review the actual artifacts that will be
>> deployed, as well as ensuring that artifacts cannot be accidentally
>> deployed.

Sorry, I was referring to the Maven artifacts, which is what went
wrong with Net.

> 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.

AIUI the ASF release is the *source*, which is normally also released to Maven.

We don't have to use Nexus for non-Maven artifacts.

IIRC, previously there was little or no visibility of what Maven
artifacts would be released, and they were not always voted on.

> I also don't see why we *must* rely on proprietary software to
> manage replication.  We have been replicating actual release
> artifacts to hundreds - maybe thousands, by now - of Apache mirrors
> for 10+ years now using rsynch.  I don't buy the argument that we
> need to control access better to ibiblio-rsynch, since the same
> applies to dist/ which is vastly more important and we trust RMs to
> manage carefully.

Note that accidental dist releases can easily be removed by us (and
they will automatically disappear from mirrors).

Removing Maven releases is much harder, and is not in our direct control.

I don't really care whether we use Ant or Maven or whatever.
However, I do care that any releases are subject to proper voting
controls, and by that I mean we should vote on all release artifacts.

Nexus seems to me to be a useful part of that process.
Without it there have been some errors, not only Net, but also
commons-daemon:commons-daemon:1.0.3 was somehow released with groupId
org.apache.commons, presumably because it was added to the wrong
directory on people. There may be other examples.

> Phil
>> Nexus release process is described here:
>>
>> http://www.apache.org/dev/publishing-maven-artifacts.html
>>
>>> Matt
>>>
>>>>> Niall
>>>>>
>>>>>>  I would ask, however,
>>>>>> that those arguing for the "automagical" approach take a hard look
>>>>>> at how many volunteer hours are being spent trying to get
>>>>>> maven/nexus to be a release manager and how comparatively little
>>>>>> time those of us who take the "manual" approach spend getting our
>>>>>> releases built and deployed.  While I certainly can't claim to
>>>>>> produce perfect artifacts (much less code :), I will also point out
>>>>>> that the only major release quality problem that we have had
>>>>>> recently was the inadvertent release of a [net] version while
>>>>>> fiddling with the release plugin.  I don't at all buy the argument
>>>>>> that the manual approach is "error-prone" as it allows more and
>>>>>> better opportunities for inspection by the RM and community at each
>>>>>> stage.
>>>>>
>>>>>
>>>>>
>>>>>> Phil
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Jochen Wiedmann <jo...@gmail.com>]

On Thu, Mar 31, 2011 at 5:46 PM, sebb <se...@gmail.com> wrote:

> If they are left in Nexus staging, AFAIK they end up in Maven Central
> when promoted.

And your point is?


-- 
I Am What I Am And That's All What I Yam (Popeye)

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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb <se...@gmail.com>]

On 31 March 2011 12:05, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Thu, Mar 31, 2011 at 1:36 AM, sebb <se...@gmail.com> wrote:
>
>> AFAIK, wget alone won't do, as the files also have to be deleted.
>
> Why? There's no problem with leaving them where they are.

If they are left in Nexus staging, AFAIK they end up in Maven Central
when promoted.

>
>> Also, it would be best if that part of the process could be done from
>> the users system, rather than having to login to people.a.o and run
>> commands there.
>>
>> If that could be automated, I would be happy, but would everyone else?
>
> Nothing wrong with that idea, because that area isn't covered by
> either Nexus nor the maven-release-plugin. The work that we spend here
> might even be adopted by other Apache projects. But that wasn't the
> initial point of the discussion, was it?

I thoought the point was to improve the release process.
Since we already use Nexus, I was exploring how the release of dist/
archives could be improved.

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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Jochen Wiedmann <jo...@gmail.com>]

On Thu, Mar 31, 2011 at 1:36 AM, sebb <se...@gmail.com> wrote:

> AFAIK, wget alone won't do, as the files also have to be deleted.

Why? There's no problem with leaving them where they are.


> Also, it would be best if that part of the process could be done from
> the users system, rather than having to login to people.a.o and run
> commands there.
>
> If that could be automated, I would be happy, but would everyone else?

Nothing wrong with that idea, because that area isn't covered by
either Nexus nor the maven-release-plugin. The work that we spend here
might even be adopted by other Apache projects. But that wasn't the
initial point of the discussion, was it?



-- 
I Am What I Am And That's All What I Yam (Popeye)

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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb <se...@gmail.com>]

On 31 March 2011 04:00, Phil Steitz <ph...@gmail.com> wrote:
> On 3/30/11 6:57 PM, sebb wrote:
>> On 31 March 2011 01:38, Phil Steitz <ph...@gmail.com> wrote:
>>> On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
>>>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Phil Steitz <ph...@gmail.com>]

On 3/30/11 6:57 PM, sebb wrote:
> On 31 March 2011 01:38, Phil Steitz <ph...@gmail.com> wrote:
>> On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
>>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@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.
>> 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.

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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Phil Steitz <ph...@gmail.com>]

On 3/30/11 7:07 PM, Ralph Goers wrote:
> I'm seeing a lot of complaining on these threads but no actual proposal.
I started the thread with a proposal, which was to standardize on
the process documented on the web site.  I know you don't like that
process and I am not going to insist that we force everyone to use
the same process.  That is obviously not going to be possible, since
several of us will -1 forcing everyone to use either Nexus or the
maven release plugin.

An improvement of the process on the web site has been suggested,
basically replacing step 3 with an Ant script that pushes maven
artifacts generated by the build automatically.  I will get a
prototype for that working when I cut my next release.

Phil
>  If the proposal is to move away from Maven/Nexus for a release for all of commons I'll vote -1.  OTOH, If some release managers want to do the release some other way I'm not going to force them to use Maven/Nexus.
>
> Ralph
>
>
> On Mar 30, 2011, at 6:57 PM, sebb wrote:
>
>> On 31 March 2011 01:38, Phil Steitz <ph...@gmail.com> wrote:
>>> On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
>>>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@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?
>>
>>> 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.
>>
>>>>  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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Ralph Goers <ra...@dslextreme.com>]

I'm seeing a lot of complaining on these threads but no actual proposal. If the proposal is to move away from Maven/Nexus for a release for all of commons I'll vote -1.  OTOH, If some release managers want to do the release some other way I'm not going to force them to use Maven/Nexus.

Ralph


On Mar 30, 2011, at 6:57 PM, sebb wrote:

> On 31 March 2011 01:38, Phil Steitz <ph...@gmail.com> wrote:
>> On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
>>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@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?
> 
>> 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.
> 
>>>  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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb <se...@gmail.com>]

On 31 March 2011 01:38, Phil Steitz <ph...@gmail.com> wrote:
> On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@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?

> 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.

>>  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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb <se...@gmail.com>]

On 31 March 2011 00:22, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@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. 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).

IMO, moving the non-Maven files out of Nexus is the main irritation
with the way it works at present.

AFAIK, wget alone won't do, as the files also have to be deleted.

Also, it would be best if that part of the process could be done from
the users system, rather than having to login to people.a.o and run
commands there.

If that could be automated, I would be happy, but would everyone else?

>
>> 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.

AIUI Archive does not currently support staging.

> Jochen
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> 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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Ralph Goers <ra...@dslextreme.com>]

On Mar 31, 2011, at 8:49 AM, sebb wrote:

> On 31 March 2011 12:08, Jochen Wiedmann <jo...@gmail.com> wrote:
>> On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz <ph...@gmail.com> wrote:
>> 
>>> 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.
>>> 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.
>> 
>> You don't get the point of Nexus and the maven-release-plugin, Phil.
>> The point is that these files (hashes and sigs) are already created,
>> ready to use and, indeed, will be simply moved to /dist, just as you
>> are suggesting.
> 
> Does the release plugin move the files from the staging directory to /dist then?
> 
> Or does it move the RM's copies of the files to /dist?

Although you said you don't like that the Nexus plugin allows manipulating the repo, I could see creating a maven project that does nothing but the required operations to promote the maven artifacts and move the non-maven artifacts to /dist.  Of course, a Java program could also be used that invokes the Nexus APIs, etc.

Ralph

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb <se...@gmail.com>]

On 31 March 2011 12:08, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz <ph...@gmail.com> wrote:
>
>> 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.
>> 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.
>
> You don't get the point of Nexus and the maven-release-plugin, Phil.
> The point is that these files (hashes and sigs) are already created,
> ready to use and, indeed, will be simply moved to /dist, just as you
> are suggesting.

Does the release plugin move the files from the staging directory to /dist then?

Or does it move the RM's copies of the files to /dist?

>
>> 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?
>
> As I said: Your "little script" would simply be duplicating the
> maven-release-plugin. Which is in no way "little".

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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Jochen Wiedmann <jo...@gmail.com>]

On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz <ph...@gmail.com> wrote:

> 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.
> 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.

You don't get the point of Nexus and the maven-release-plugin, Phil.
The point is that these files (hashes and sigs) are already created,
ready to use and, indeed, will be simply moved to /dist, just as you
are suggesting.


> 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?

As I said: Your "little script" would simply be duplicating the
maven-release-plugin. Which is in no way "little".





-- 
I Am What I Am And That's All What I Yam (Popeye)

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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Phil Steitz <ph...@gmail.com>]

On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <ph...@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. 
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.
>  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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Phil Steitz <ph...@gmail.com>]

On 3/29/11 8:33 AM, sebb wrote:
> On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>>  After another nightmare by an RM who has not cut a release in a
>>>>> while, I think we need to do something.  The documentation on the
>>>>> Commons web pages describes a process that works.  I suggest that we
>>>>> standardize on that process, adding some simple automation scripts
>>>>> that RMs can choose to use or not to use for the manual steps and
>>>>> stop fussing with Nexus or the maven release plugin.  I cut an RC
>>> We need to keep Nexus, but I agree about the release plugin - see below.
>>>
>>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>>> the [pool] tests to complete) and will likely spend about that same
>>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>>> our simple, file-and-directory-based replication infrastructure to
>>>>> get maven artifacts pushed to the maven repos.  I do use a simple
>>>>> shell script to manage invoking the maven commands and copying files
>>>>> around to reduce the required time from, say an hour, to 25
>>>>> minutes.  The script is in svn.
>>>>>
>>>>> I prefer the "manual" approach for the following reasons:
>>>>>
>>>>> 1.  I know what it does.  Exactly, every time.  I know that exactly
>>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>>> committed tag is used to build everything.  The process includes
>>>>> local generation of artifacts that I can inspect and test locally
>>>>> and verify sigs.  I know at each step exactly what is being pushed
>>>>> where.
>>>>>
>>>>> 2.  I know that it works.  Every time.  No pom-tweaking,
>>>>> plugin-munging or other half-success management required.
>>>>>
>>>>> 3.  It has no commercial / proprietary dependencies.  The scripts
>>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>>
>>>>> I know others have different opinions on this.  It could be we need
>>>>> to support both ways of cutting releases.
>>>> AIUI then the deployment to the maven repository is either by dropping
>>>> the artifacts manually in
>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>>> Nexus. I think once a component switches to Nexus, then the manual
>>>> process doesn't work.
>>> Yes, that is true.
>>>
>>> Also, had the [net] release been using Nexus, it would have required 2
>>> additional manual stages to close and then release the Maven
>>> artifacts.
>>> It is impossible to accidentally release Maven artifacts using Maven
>>> command-line when using a staging manager such as Nexus.
>>>
>>> But I agree that using manual processes up to that point is better
>>> than trying to use the Maven release plugin.
>> My assumption is that the Nexus stuff is supposed to work and make
>> life easier.  If it doesn't, I suppose we shouldn't use it.  Is it a
>> training issue, such that none of us simply knows exactly what it is
>> we ought to expect the process to do, and how it will do it?  This
>> type of thing is my chief complaint about Maven in general:  it's hard
>> to understand what's going on once you get a level or two of parent
>> POMs in there.  If it's just a matter of "we haven't discovered the
>> precise incantations that make the release plugin + Nexus instance do
>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>> walking one of us (who solemnly vows to document the entire experience
>> in full detail) through the entire lifecycle.
> Nexus is effectively a proxy, and has little bearing on how Maven
> deploy or release work.
> The artifacts end up in Nexus rather than in a directory that is
> auto-synched to Maven Central.
>
> This makes it easy to review the actual artifacts that will be
> deployed, as well as ensuring that artifacts cannot be accidentally
> deployed.
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.

I also don't see why we *must* rely on proprietary software to
manage replication.  We have been replicating actual release
artifacts to hundreds - maybe thousands, by now - of Apache mirrors
for 10+ years now using rsynch.  I don't buy the argument that we
need to control access better to ibiblio-rsynch, since the same
applies to dist/ which is vastly more important and we trust RMs to
manage carefully.

Phil
> Nexus release process is described here:
>
> http://www.apache.org/dev/publishing-maven-artifacts.html
>
>> Matt
>>
>>>> Niall
>>>>
>>>>>  I would ask, however,
>>>>> that those arguing for the "automagical" approach take a hard look
>>>>> at how many volunteer hours are being spent trying to get
>>>>> maven/nexus to be a release manager and how comparatively little
>>>>> time those of us who take the "manual" approach spend getting our
>>>>> releases built and deployed.  While I certainly can't claim to
>>>>> produce perfect artifacts (much less code :), I will also point out
>>>>> that the only major release quality problem that we have had
>>>>> recently was the inadvertent release of a [net] version while
>>>>> fiddling with the release plugin.  I don't at all buy the argument
>>>>> that the manual approach is "error-prone" as it allows more and
>>>>> better opportunities for inspection by the RM and community at each
>>>>> stage.
>>>>
>>>>
>>>>
>>>>> Phil
>>>> ---------------------------------------------------------------------
>>>> 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
>
>


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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb <se...@gmail.com>]

On 29 March 2011 16:20, Matt Benson <gu...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
>> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>  After another nightmare by an RM who has not cut a release in a
>>>> while, I think we need to do something.  The documentation on the
>>>> Commons web pages describes a process that works.  I suggest that we
>>>> standardize on that process, adding some simple automation scripts
>>>> that RMs can choose to use or not to use for the manual steps and
>>>> stop fussing with Nexus or the maven release plugin.  I cut an RC
>>
>> We need to keep Nexus, but I agree about the release plugin - see below.
>>
>>>> last night in 25 minutes (about 15 of which were spent waiting for
>>>> the [pool] tests to complete) and will likely spend about that same
>>>> amount of time deploying the artifacts to dist/ and what remains of
>>>> our simple, file-and-directory-based replication infrastructure to
>>>> get maven artifacts pushed to the maven repos.  I do use a simple
>>>> shell script to manage invoking the maven commands and copying files
>>>> around to reduce the required time from, say an hour, to 25
>>>> minutes.  The script is in svn.
>>>>
>>>> I prefer the "manual" approach for the following reasons:
>>>>
>>>> 1.  I know what it does.  Exactly, every time.  I know that exactly
>>>> the binaries that we vote on get deployed to dist/ and exactly the
>>>> committed tag is used to build everything.  The process includes
>>>> local generation of artifacts that I can inspect and test locally
>>>> and verify sigs.  I know at each step exactly what is being pushed
>>>> where.
>>>>
>>>> 2.  I know that it works.  Every time.  No pom-tweaking,
>>>> plugin-munging or other half-success management required.
>>>>
>>>> 3.  It has no commercial / proprietary dependencies.  The scripts
>>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>>
>>>> I know others have different opinions on this.  It could be we need
>>>> to support both ways of cutting releases.
>>>
>>> AIUI then the deployment to the maven repository is either by dropping
>>> the artifacts manually in
>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>>> Nexus. I think once a component switches to Nexus, then the manual
>>> process doesn't work.
>>
>> Yes, that is true.
>>
>> Also, had the [net] release been using Nexus, it would have required 2
>> additional manual stages to close and then release the Maven
>> artifacts.
>> It is impossible to accidentally release Maven artifacts using Maven
>> command-line when using a staging manager such as Nexus.
>>
>> But I agree that using manual processes up to that point is better
>> than trying to use the Maven release plugin.
>
> My assumption is that the Nexus stuff is supposed to work and make
> life easier.  If it doesn't, I suppose we shouldn't use it.  Is it a
> training issue, such that none of us simply knows exactly what it is
> we ought to expect the process to do, and how it will do it?  This
> type of thing is my chief complaint about Maven in general:  it's hard
> to understand what's going on once you get a level or two of parent
> POMs in there.  If it's just a matter of "we haven't discovered the
> precise incantations that make the release plugin + Nexus instance do
> what we mean with no fuss," perhaps we could cajole Brian Fox into
> walking one of us (who solemnly vows to document the entire experience
> in full detail) through the entire lifecycle.

Nexus is effectively a proxy, and has little bearing on how Maven
deploy or release work.
The artifacts end up in Nexus rather than in a directory that is
auto-synched to Maven Central.

This makes it easy to review the actual artifacts that will be
deployed, as well as ensuring that artifacts cannot be accidentally
deployed.

Nexus release process is described here:

http://www.apache.org/dev/publishing-maven-artifacts.html

> Matt
>
>>
>>> Niall
>>>
>>>>  I would ask, however,
>>>> that those arguing for the "automagical" approach take a hard look
>>>> at how many volunteer hours are being spent trying to get
>>>> maven/nexus to be a release manager and how comparatively little
>>>> time those of us who take the "manual" approach spend getting our
>>>> releases built and deployed.  While I certainly can't claim to
>>>> produce perfect artifacts (much less code :), I will also point out
>>>> that the only major release quality problem that we have had
>>>> recently was the inadvertent release of a [net] version while
>>>> fiddling with the release plugin.  I don't at all buy the argument
>>>> that the manual approach is "error-prone" as it allows more and
>>>> better opportunities for inspection by the RM and community at each
>>>> stage.
>>>
>>>
>>>
>>>
>>>> Phil
>>>
>>> ---------------------------------------------------------------------
>>> 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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Matt Benson <gu...@gmail.com>]

On Tue, Mar 29, 2011 at 10:08 AM, sebb <se...@gmail.com> wrote:
> On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>  After another nightmare by an RM who has not cut a release in a
>>> while, I think we need to do something.  The documentation on the
>>> Commons web pages describes a process that works.  I suggest that we
>>> standardize on that process, adding some simple automation scripts
>>> that RMs can choose to use or not to use for the manual steps and
>>> stop fussing with Nexus or the maven release plugin.  I cut an RC
>
> We need to keep Nexus, but I agree about the release plugin - see below.
>
>>> last night in 25 minutes (about 15 of which were spent waiting for
>>> the [pool] tests to complete) and will likely spend about that same
>>> amount of time deploying the artifacts to dist/ and what remains of
>>> our simple, file-and-directory-based replication infrastructure to
>>> get maven artifacts pushed to the maven repos.  I do use a simple
>>> shell script to manage invoking the maven commands and copying files
>>> around to reduce the required time from, say an hour, to 25
>>> minutes.  The script is in svn.
>>>
>>> I prefer the "manual" approach for the following reasons:
>>>
>>> 1.  I know what it does.  Exactly, every time.  I know that exactly
>>> the binaries that we vote on get deployed to dist/ and exactly the
>>> committed tag is used to build everything.  The process includes
>>> local generation of artifacts that I can inspect and test locally
>>> and verify sigs.  I know at each step exactly what is being pushed
>>> where.
>>>
>>> 2.  I know that it works.  Every time.  No pom-tweaking,
>>> plugin-munging or other half-success management required.
>>>
>>> 3.  It has no commercial / proprietary dependencies.  The scripts
>>> are optional and are in any case, ASF-licensed, committed to svn.
>>>
>>> I know others have different opinions on this.  It could be we need
>>> to support both ways of cutting releases.
>>
>> AIUI then the deployment to the maven repository is either by dropping
>> the artifacts manually in
>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
>> Nexus. I think once a component switches to Nexus, then the manual
>> process doesn't work.
>
> Yes, that is true.
>
> Also, had the [net] release been using Nexus, it would have required 2
> additional manual stages to close and then release the Maven
> artifacts.
> It is impossible to accidentally release Maven artifacts using Maven
> command-line when using a staging manager such as Nexus.
>
> But I agree that using manual processes up to that point is better
> than trying to use the Maven release plugin.

My assumption is that the Nexus stuff is supposed to work and make
life easier.  If it doesn't, I suppose we shouldn't use it.  Is it a
training issue, such that none of us simply knows exactly what it is
we ought to expect the process to do, and how it will do it?  This
type of thing is my chief complaint about Maven in general:  it's hard
to understand what's going on once you get a level or two of parent
POMs in there.  If it's just a matter of "we haven't discovered the
precise incantations that make the release plugin + Nexus instance do
what we mean with no fuss," perhaps we could cajole Brian Fox into
walking one of us (who solemnly vows to document the entire experience
in full detail) through the entire lifecycle.

Matt

>
>> Niall
>>
>>>  I would ask, however,
>>> that those arguing for the "automagical" approach take a hard look
>>> at how many volunteer hours are being spent trying to get
>>> maven/nexus to be a release manager and how comparatively little
>>> time those of us who take the "manual" approach spend getting our
>>> releases built and deployed.  While I certainly can't claim to
>>> produce perfect artifacts (much less code :), I will also point out
>>> that the only major release quality problem that we have had
>>> recently was the inadvertent release of a [net] version while
>>> fiddling with the release plugin.  I don't at all buy the argument
>>> that the manual approach is "error-prone" as it allows more and
>>> better opportunities for inspection by the RM and community at each
>>> stage.
>>
>>
>>
>>
>>> Phil
>>
>> ---------------------------------------------------------------------
>> 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

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb <se...@gmail.com>]

On 29 March 2011 16:02, Niall Pemberton <ni...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <ph...@gmail.com> wrote:
>>  After another nightmare by an RM who has not cut a release in a
>> while, I think we need to do something.  The documentation on the
>> Commons web pages describes a process that works.  I suggest that we
>> standardize on that process, adding some simple automation scripts
>> that RMs can choose to use or not to use for the manual steps and
>> stop fussing with Nexus or the maven release plugin.  I cut an RC

We need to keep Nexus, but I agree about the release plugin - see below.

>> last night in 25 minutes (about 15 of which were spent waiting for
>> the [pool] tests to complete) and will likely spend about that same
>> amount of time deploying the artifacts to dist/ and what remains of
>> our simple, file-and-directory-based replication infrastructure to
>> get maven artifacts pushed to the maven repos.  I do use a simple
>> shell script to manage invoking the maven commands and copying files
>> around to reduce the required time from, say an hour, to 25
>> minutes.  The script is in svn.
>>
>> I prefer the "manual" approach for the following reasons:
>>
>> 1.  I know what it does.  Exactly, every time.  I know that exactly
>> the binaries that we vote on get deployed to dist/ and exactly the
>> committed tag is used to build everything.  The process includes
>> local generation of artifacts that I can inspect and test locally
>> and verify sigs.  I know at each step exactly what is being pushed
>> where.
>>
>> 2.  I know that it works.  Every time.  No pom-tweaking,
>> plugin-munging or other half-success management required.
>>
>> 3.  It has no commercial / proprietary dependencies.  The scripts
>> are optional and are in any case, ASF-licensed, committed to svn.
>>
>> I know others have different opinions on this.  It could be we need
>> to support both ways of cutting releases.
>
> AIUI then the deployment to the maven repository is either by dropping
> the artifacts manually in
> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
> Nexus. I think once a component switches to Nexus, then the manual
> process doesn't work.

Yes, that is true.

Also, had the [net] release been using Nexus, it would have required 2
additional manual stages to close and then release the Maven
artifacts.
It is impossible to accidentally release Maven artifacts using Maven
command-line when using a staging manager such as Nexus.

But I agree that using manual processes up to that point is better
than trying to use the Maven release plugin.

> Niall
>
>>  I would ask, however,
>> that those arguing for the "automagical" approach take a hard look
>> at how many volunteer hours are being spent trying to get
>> maven/nexus to be a release manager and how comparatively little
>> time those of us who take the "manual" approach spend getting our
>> releases built and deployed.  While I certainly can't claim to
>> produce perfect artifacts (much less code :), I will also point out
>> that the only major release quality problem that we have had
>> recently was the inadvertent release of a [net] version while
>> fiddling with the release plugin.  I don't at all buy the argument
>> that the manual approach is "error-prone" as it allows more and
>> better opportunities for inspection by the RM and community at each
>> stage.
>
>
>
>
>> Phil
>
> ---------------------------------------------------------------------
> 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