Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of esjewett@gmail.com designates
 209.85.160.47 as permitted sender)
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;
        b=WQFyUt5xWFB4L+Vxg97DWM/hncaIs4U+E47SWfNUvHPpZ7n9MdJSZWVV9r7J5YzLBE
         hWPMN+rhOhw5xFY2UGF8FCqHAFP7+oz8zVtkS+TaOFS7L2ncUsbLKCdaXIlEut5youqZ
         cPSYoqnMlnrfZvtofm9OrjQfh3PN4J40c5sUM=
MIME-Version: 1.0
In-Reply-To: <68f4a0e81003020731l2a98c0e1o18e99d77d0913e25@mail.gmail.com>
References: <fa2d9f451002232054v4d2beb6aha1be78513b86de87@mail.gmail.com>
	 <68f4a0e81003011457t45b018e8we029ae5315bbe3a5@mail.gmail.com>
	 <3d89f1771003011506p417dbb82x9e99344a75004616@mail.gmail.com>
	 <68f4a0e81003011514k5ecfc3e6pea346935a85bb961@mail.gmail.com>
	 <77510119-96FC-4053-BD27-F0E80F9E82B4@gmail.com>
	 <fa2d9f451003020021t69fca21fna0d499c6c556174@mail.gmail.com>
	 <f767f0601003020319j204c9952tbc71ef26f367c0e@mail.gmail.com>
	 <68f4a0e81003020628s1bb694bbr63a1383f67153957@mail.gmail.com>
	 <3d89f1771003020700n90bbbc7j802a76dbd111c397@mail.gmail.com>
	 <68f4a0e81003020731l2a98c0e1o18e99d77d0913e25@mail.gmail.com>
Date: Sun, 7 Mar 2010 11:33:12 -0600
Message-ID: <68f4a0e81003070933i680af8b8y28089dbc230b2376@mail.gmail.com>
Subject: Re: Release 1.0-RC2 in Jira
From: Ethan Jewett <esjewett@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Is it OK if I move all open the Jira items out of Release 1.0-RC2
except for ESME-162 (mailto action crashes server)? I would like to
move all of these items into Release 1.1 in Jira.

For the closed items, I think they were mostly in Release 1.0-RC1, so
we should leave them in RC2 in order to get them into the release
notes. However, if there are any closed items that were fixed after
the RC1 release, I think we should move them to release 1.1 as well.

Ethan

On Tue, Mar 2, 2010 at 9:31 AM, Ethan Jewett <esjewett@gmail.com> wrote:
> Dick,
>
> Yes, I think only bug fixes should go into 1.0 RCs. Actually, I think
> once we get to RC stage, only really bad bugs (security, crashes) and
> their fixes should go into the RC. All other bugs should get pushed to
> a subsequent release.
>
> Gianugo,
>
> Actually, it's not orthogonal at all. It's the original topic of the
> discussion ;-) And because of that, let's focus on topic #1 and forget
> that I mentioned #2. Though I think it's a valid concern, I recognize
> that if the mentors don't understand the concern, I must be missing
> something.
>
> Ethan
>
> On Tue, Mar 2, 2010 at 10:00 AM, Gianugo Rabellino
> <g.rabellino@sourcesense.com> wrote:
>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <esjewett@gmail.com> wrote:
>>> I only have two things to add here (assuming that this is the
>>> definition of a release within Apache):
>>>
>>> 1. My original concern: I think that nearly all the changes in JIRA
>>> that are assigned to Release-1.0-RC2 should be moved to something else
>>> called Release-1.1. We already agreed on a locked scope for release
>>> 1.0 and I don't think we should add anything to 1.0 release candidates
>>> aside from things we have agreed are blocking bugs. ESME-162 (mailto
>>> actions crash the server) is probably an example of something that
>>> should stay in Release-1.0-RC2. ESME-100 (finish Web UI) is an example
>>> of something that should *not* stay in Release-1.0-RC2.
>>
>> This is a valid concern, although orthogonal to the discussion here.
>> Still, yes, I would agree RCs should not contain any new features as
>> they might introduce bugs or regressions.
>>
>>> 2. Not to pick on our mentors, but this definition doesn't make any
>>> sense to me. It is aligned with the official Apache release definition
>>> at http://www.apache.org/dev/release.html#what but we've just moved
>>> the question from the definition of "release" to the definition of
>>> "the act of publishing it beyond the ESME group of developers (this
>>> mailing list)". If this is the definition of an Apache release, then
>>> the publicly accessible SVN repository is a release. I have a hard
>>> time believing that if I do an export from the ESME SVN repo and
>>> upload it to my people.apache.org page to facilitate testing that this
>>> constitutes a significantly different action from sending someone
>>> instructions on exporting the SVN repo themselves.
>>
>> As Richard pointed out, the real difference between "do an svn
>> checkout -r xxx" and "grab this tarball we just released" is consensus
>> coming from a community blessing by means of a vote. It's not peanuts,
>> it makes all the difference.
>>
>>> I suggest that we work with a narrower definition. Something like "a
>>> signed tarball published to http://www.apache.org/dist/incubator/esme/
>>> and advertised on the public ESME website and/or the public mailing
>>> list is a release".
>>
>> You're more than welcome to argue your case, as no ASF procedure is
>> carved in stone, but know that you should make sure you place your
>> soapbox on front of the right audience - this is not the place to
>> discuss what the ASF, as a whole, considers a release to be -
>> general@incubator might be a better starting point. Until the current
>> definition stands, so does the current process.
>>
>> --
>> Gianugo Rabellino
>> M: +44 779 5364 932 / +39 389 44 26 846
>> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>>
>