On 29 March 2011 16:52, Phil Steitz <phil.ste...@gmail.com> wrote: > 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.
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-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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
