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.222.178 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:content-transfer-encoding;
        b=kft33NyjahO5fO27ijnC2uBzzGhQ+3vEnrsj0urTSAGaS+Kda3F8Im+1FKWeVYtcAg
         iDI6qKBou10sh87Qm3wwmWFFCbMb+PUYiJebmWqzUbNrzJhkYOxVsknGdRdsBS2rflpP
         jztpY/hOdQKX3FKfwuPMrlg1/lv1r/UD9fapI=
MIME-Version: 1.0
In-Reply-To: <14AABD28-F2AC-4427-9EC2-AE437080299D@gmail.com>
References: <fa2d9f451002232054v4d2beb6aha1be78513b86de87@mail.gmail.com>
	 <3d89f1771003020700n90bbbc7j802a76dbd111c397@mail.gmail.com>
	 <68f4a0e81003020731l2a98c0e1o18e99d77d0913e25@mail.gmail.com>
	 <68f4a0e81003070933i680af8b8y28089dbc230b2376@mail.gmail.com>
	 <fa2d9f451003072343n5ffac612y94c0682aef4ec7b6@mail.gmail.com>
	 <68f4a0e81003080829j65c1e335m4222fe035a3b8516@mail.gmail.com>
	 <fa2d9f451003080907v4cd9837an3eefd411ae42a90c@mail.gmail.com>
	 <68f4a0e81003080928u6507dcedle823b9ad67a0e62a@mail.gmail.com>
	 <fa2d9f451003081048q146cb8fep94e7177d1aeeb540@mail.gmail.com>
	 <14AABD28-F2AC-4427-9EC2-AE437080299D@gmail.com>
Date: Thu, 11 Mar 2010 09:46:10 -0500
Message-ID: <68f4a0e81003110646m3a0d5e08pcb30d93e2b7957c@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
Content-Transfer-Encoding: quoted-printable

I've moved all open Jira issues except ESME-162 from "Release 1.0-RC2"
to "Release 1.1". A lot of these should probably be moved back to the
backlog while UI issues are prioritized for Release 1.1, but we can
have that debate later :-)

Was ESME-162 (the mailto issue) resolved? If so, can I mark it as
fixed? That will be our last issue to close in the ESME 1.0 release
schedule, though I agree that we should wait a few more days to see if
anything else comes up.

Ethan

On Mon, Mar 8, 2010 at 4:28 PM, Anne Kathrine Petter=F8e
<yojibee@gmail.com> wrote:
> Sounds good to me too.
>
> - anne
>
>
> On 8. mars 2010, at 19.48, Richard Hirsch wrote:
>
>> Sounds good to me.
>>
>> Why don't we wait a week or two to see if anything else pops up and
>> then cut a new release.
>>
>> D.
>>
>> On Mon, Mar 8, 2010 at 6:28 PM, Ethan Jewett <esjewett@gmail.com> wrote:
>>> Sound good to me. Looks to me like this last one was revision 918616
>>> and the mailto issue was revision 917187.
>>>
>>> So our release 1.0 would be the snapshot frozen in the 1.0-RC1 tag,
>>> plus these two changes. Does that sound right to everyone?
>>>
>>> Thanks,
>>> Ethan
>>>
>>> On Mon, Mar 8, 2010 at 11:07 AM, Richard Hirsch <hirsch.dick@gmail.com>=
 wrote:
>>>> I'd also like to include the exception that Vassil fixed - look at the
>>>> esme-dev mailing list thread "Strange Exception on Streams Page"
>>>>
>>>> D.
>>>>
>>>> On Mon, Mar 8, 2010 at 5:29 PM, Ethan Jewett <esjewett@gmail.com> wrot=
e:
>>>>> I'd say that they shouldn't go in as a rule. There are always
>>>>> exceptions, but checking in new changes generally destabilizes the
>>>>> release. Based on what I see in Jira, the only code change I'd like t=
o
>>>>> see in 1.0-RC2 or 1.0 would be the mailto fix.
>>>>>
>>>>> I think that with the mailto fix, we could just release 1.0 (not
>>>>> another RC) at this point and then concentrate on a 1.1 release with
>>>>> the new UI.
>>>>>
>>>>> Ethan
>>>>>
>>>>> On Mon, Mar 8, 2010 at 1:43 AM, Richard Hirsch <hirsch.dick@gmail.com=
> wrote:
>>>>>> OK.
>>>>>>
>>>>>> What about code changes / bug fixes that happened after the release
>>>>>> but weren't linked to a particular JIRA item?
>>>>>>
>>>>>> How do we proceed with the 1.0 release. We are now finding a few bug=
s
>>>>>> but are mostly improvements rather than bug fixes. When do we cut th=
e
>>>>>> next RC and when we do declare a real release (1.0).
>>>>>>
>>>>>> On Sun, Mar 7, 2010 at 6:33 PM, Ethan Jewett <esjewett@gmail.com> wr=
ote:
>>>>>>> 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> w=
rote:
>>>>>>>> Dick,
>>>>>>>>
>>>>>>>> Yes, I think only bug fixes should go into 1.0 RCs. Actually, I th=
ink
>>>>>>>> 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 pushe=
d to
>>>>>>>> a subsequent release.
>>>>>>>>
>>>>>>>> Gianugo,
>>>>>>>>
>>>>>>>> Actually, it's not orthogonal at all. It's the original topic of t=
he
>>>>>>>> discussion ;-) And because of that, let's focus on topic #1 and fo=
rget
>>>>>>>> that I mentioned #2. Though I think it's a valid concern, I recogn=
ize
>>>>>>>> that if the mentors don't understand the concern, I must be missin=
g
>>>>>>>> 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 J=
IRA
>>>>>>>>>> that are assigned to Release-1.0-RC2 should be moved to somethin=
g else
>>>>>>>>>> called Release-1.1. We already agreed on a locked scope for rele=
ase
>>>>>>>>>> 1.0 and I don't think we should add anything to 1.0 release cand=
idates
>>>>>>>>>> aside from things we have agreed are blocking bugs. ESME-162 (ma=
ilto
>>>>>>>>>> actions crash the server) is probably an example of something th=
at
>>>>>>>>>> should stay in Release-1.0-RC2. ESME-100 (finish Web UI) is an e=
xample
>>>>>>>>>> of something that should *not* stay in Release-1.0-RC2.
>>>>>>>>>
>>>>>>>>> This is a valid concern, although orthogonal to the discussion he=
re.
>>>>>>>>> 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 defi=
nition
>>>>>>>>>> at http://www.apache.org/dev/release.html#what but we've just mo=
ved
>>>>>>>>>> the question from the definition of "release" to the definition =
of
>>>>>>>>>> "the act of publishing it beyond the ESME group of developers (t=
his
>>>>>>>>>> mailing list)". If this is the definition of an Apache release, =
then
>>>>>>>>>> the publicly accessible SVN repository is a release. I have a ha=
rd
>>>>>>>>>> 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 tha=
t this
>>>>>>>>>> constitutes a significantly different action from sending someon=
e
>>>>>>>>>> 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 cons=
ensus
>>>>>>>>> coming from a community blessing by means of a vote. It's not pea=
nuts,
>>>>>>>>> it makes all the difference.
>>>>>>>>>
>>>>>>>>>> I suggest that we work with a narrower definition. Something lik=
e "a
>>>>>>>>>> signed tarball published to http://www.apache.org/dist/incubator=
/esme/
>>>>>>>>>> and advertised on the public ESME website and/or the public mail=
ing
>>>>>>>>>> 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 you=
r
>>>>>>>>> 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 cur=
rent
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>