commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <>
Subject Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Date Tue, 29 Mar 2011 17:33:51 GMT
On Tue, Mar 29, 2011 at 5:18 PM, sebb <> wrote:
> On 29 March 2011 16:52, Phil Steitz <> wrote:
>> On 3/29/11 8:33 AM, sebb wrote:
>>> On 29 March 2011 16:20, Matt Benson <> wrote:
>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <> wrote:
>>>>> On 29 March 2011 16:02, Niall Pemberton <>
>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <>
>>>>>>>  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
>>>>>>> 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
>>>>>>> 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
>>>>>>> the [pool] tests to complete) and will likely spend about that
>>>>>>> amount of time deploying the artifacts to dist/ and what remains
>>>>>>> our simple, file-and-directory-based replication infrastructure
>>>>>>> get maven artifacts pushed to the maven repos.  I do use a simple
>>>>>>> shell script to manage invoking the maven commands and copying
>>>>>>> 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
>>>>>>> the binaries that we vote on get deployed to dist/ and exactly
>>>>>>> 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
>>>>>>> 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
>>>>>>> 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
>>>>>> OR by
>>>>>> 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
>>>>> 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.


>> 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:
>>>> Matt
>>>>>> Niall
>>>>>>>  I would ask, however,
>>>>>>> that those arguing for the "automagical" approach take a hard
>>>>>>> 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
>>>>>>> releases built and deployed.  While I certainly can't claim
>>>>>>> produce perfect artifacts (much less code :), I will also point
>>>>>>> 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
>>>>>>> stage.
>>>>>>> Phil
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>>> For additional commands, e-mail:
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message