On 29 March 2011 20:56, Niall Pemberton <niall.pember...@gmail.com> wrote: > On Tue, Mar 29, 2011 at 8:08 PM, sebb <seb...@gmail.com> wrote: >> On 29 March 2011 18:33, Niall Pemberton <niall.pember...@gmail.com> wrote: >>> On Tue, Mar 29, 2011 at 5:18 PM, sebb <seb...@gmail.com> wrote: >>>> 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. >>> >>> 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-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
