Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.200.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=YDf87IACUac6AGceGlX79CfGp8Uu9mCpBDW+lcQCLNd+ZiJsmb9BsqEOx64eiwvZVmHaCef1C5TcTbE7e8SZ2d1tZoDveL1zOOUpMTHkVjdVqkY25h9meBmVMdsuB/YUHyIWrWOnCXSbqYEjWyVqNEzi4V8MWuvPuOlL5wwGMaY=
Message-ID: <8a81b4af0803222323x3e4d4901hf01811ffe157bdde@mail.gmail.com>
Date: Sat, 22 Mar 2008 23:23:31 -0700
From: "Phil Steitz" <phil.steitz@gmail.com>
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: [m2][PROPOSAL] Release process
In-Reply-To: <ce1f2ea80803222123h25f14d5elb25b05dfb89205f7@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <ce1f2ea80803211541x65ab8044mc39cc62472dfea21@mail.gmail.com>
	 <8a81b4af0803221510v438fe3bdj198568a742f54e04@mail.gmail.com>
	 <adba96190803221816u74870e6mfd5addec88b8cc8a@mail.gmail.com>
	 <8a81b4af0803221934j548e002di63b029ebcff20ea@mail.gmail.com>
	 <ce1f2ea80803222123h25f14d5elb25b05dfb89205f7@mail.gmail.com>

>  > I don't see why it should be "illegal" to publish an RC to the
>  >  snapshot repo.  We do not distinguish "stable", "ga", "beta" etc here
>  >  in Commons.  We have releases and things that are not yet released.  I
>  >  don't see why we need yet another repo for RCs.  We - at least I -
>  >  like for people to test with our RCs *before* we vote on them.  So
>  >  maybe its just semantics and I am calling the RCs (with "RC" in the
>  >  artifact name) "snapshots."  I don't see the need to ask people to
>  >  configure yet another special repo to test our RCs.
>  >
>  <snip/>
>
>  For the style of RCs you've described, there is nothing against
>  putting them in the m2-snap-repo. But the final RC that you describe
>  is best not placed there, because:
>
>   * Fundamentally, its a (soon-to-be) release, not a snap

Right.  I would not put the to-be-voted-on candidate there, just the
RCs leading up the the final, all of which have "RC" in their version
specs.

>   * Wendy is alluding to a limitation of the stage plugin that requires
>  the staging repo to be clean (it will currently copy all versions that
>  exist in the staging repo over to the rsync repo! -- obviously that
>  means you don't want the m2-snap-repo to also be the staging repo
>  ATM). And for folks like me who won't be correcting metadata files by
>  hand (tedious, open to operator error), the stage plugin is needed.
>
>  IMO, its not a bad idea to get folks to use an alternate repo for
>  testing RCs, it causes an increased level of awareness :-)
>
I just want to make it as simple as possible for developers to test
our RCs and I think having "RC" in the artifact name is enough to
ensure people know what they are testing.

I want to do everything possible to encourage development community
testing of release candidates. I think we do a good job - maybe even
too good a job - validating structure, formal contents and doing
static code analysis of release packages and I would like to see more
of that energy applied to validating the code itself from a functional
standpoint.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org