On 3/29/11 8:33 AM, sebb wrote: > On 29 March 2011 16:20, Matt Benson <gudnabr...@gmail.com> wrote: >> On Tue, Mar 29, 2011 at 10:08 AM, sebb <seb...@gmail.com> wrote: >>> On 29 March 2011 16:02, Niall Pemberton <niall.pember...@gmail.com> wrote: >>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <phil.ste...@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-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
