Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 98297 invoked from network); 29 Mar 2011 17:34:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 29 Mar 2011 17:34:20 -0000 Received: (qmail 91735 invoked by uid 500); 29 Mar 2011 17:34:19 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 91667 invoked by uid 500); 29 Mar 2011 17:34:19 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 91659 invoked by uid 99); 29 Mar 2011 17:34:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Mar 2011 17:34:19 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of niall.pemberton@gmail.com designates 209.85.216.43 as permitted sender) Received: from [209.85.216.43] (HELO mail-qw0-f43.google.com) (209.85.216.43) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Mar 2011 17:34:13 +0000 Received: by qwf6 with SMTP id 6so350947qwf.30 for ; Tue, 29 Mar 2011 10:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=gDx7uLRui4dLEkaotyMqGlKub2ez4tmc/yABYmdfUKY=; b=bnLLFc4wcXFr30ld9Oa6IA1IGNWImuNd0u+YeJEFYva3DhaKrf0wuYMLUvNE4DF369 EyvooAcjpnlbV5Lbh9g0KGq205rvuFlRjPw4TCAK2rR5z+K1xScz4Py2I9zsbYA5Hgfl lqRsXRkr2OCNPkK/5JkdAzzWKVB6DImt4IS54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=tVJJIhq5SdA60cXljwjUJ7p9afOXXA+Uha+0B6lMRuED9Cp9Apaknzg7SCOjPocnFE xDU1AODkWDW6+KppvysDIoL7tCVAysuQgeGdyvusabFYDJXcGVHHHQCFnlG5ZsLabs0u XhdticUIyAr57cNpJF2bZMUZY3Dc6IbEImX7s= MIME-Version: 1.0 Received: by 10.229.62.7 with SMTP id v7mr27434qch.281.1301420031785; Tue, 29 Mar 2011 10:33:51 -0700 (PDT) Received: by 10.229.49.73 with HTTP; Tue, 29 Mar 2011 10:33:51 -0700 (PDT) In-Reply-To: References: <4D915031.7060802@gmail.com> <4D91F1B5.8050206@gmail.com> <4D920050.1010501@gmail.com> Date: Tue, 29 Mar 2011 18:33:51 +0100 Message-ID: Subject: Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1 From: Niall Pemberton To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 w= rote: >>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz = wrote: >>>>>>> =A0After another nightmare by an RM who has not cut a release in a >>>>>>> while, I think we need to do something. =A0The documentation on the >>>>>>> Commons web pages describes a process that works. =A0I 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. =A0I cut an RC >>>>> We need to keep Nexus, but I agree about the release plugin - see bel= ow. >>>>> >>>>>>> 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. =A0I do use a simple >>>>>>> shell script to manage invoking the maven commands and copying file= s >>>>>>> around to reduce the required time from, say an hour, to 25 >>>>>>> minutes. =A0The script is in svn. >>>>>>> >>>>>>> I prefer the "manual" approach for the following reasons: >>>>>>> >>>>>>> 1. =A0I know what it does. =A0Exactly, every time. =A0I know that e= xactly >>>>>>> the binaries that we vote on get deployed to dist/ and exactly the >>>>>>> committed tag is used to build everything. =A0The process includes >>>>>>> local generation of artifacts that I can inspect and test locally >>>>>>> and verify sigs. =A0I know at each step exactly what is being pushe= d >>>>>>> where. >>>>>>> >>>>>>> 2. =A0I know that it works. =A0Every time. =A0No pom-tweaking, >>>>>>> plugin-munging or other half-success management required. >>>>>>> >>>>>>> 3. =A0It has no commercial / proprietary dependencies. =A0The scrip= ts >>>>>>> are optional and are in any case, ASF-licensed, committed to svn. >>>>>>> >>>>>>> I know others have different opinions on this. =A0It could be we ne= ed >>>>>>> to support both ways of cutting releases. >>>>>> AIUI then the deployment to the maven repository is either by droppi= ng >>>>>> the artifacts manually in >>>>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by usi= ng >>>>>> 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. =A0If it doesn't, I suppose we shouldn't use it. =A0Is 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? =A0This >>>> type of thing is my chief complaint about Maven in general: =A0it's ha= rd >>>> to understand what's going on once you get a level or two of parent >>>> POMs in there. =A0If 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. =A0The most important artifacts are the >> zips/tars that go to dist/. =A0These *are* the ASF release. =A0Nexus >> 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. =A0We have been replicating actual release >> artifacts to hundreds - maybe thousands, by now - of Apache mirrors >> for 10+ years now using rsynch. =A0I 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 >>>>>> >>>>>>> =A0I 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. =A0While 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. =A0I don't at all buy the argumen= t >>>>>>> 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