esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: Release 1.0-RC2 in Jira
Date Thu, 11 Mar 2010 14:46:10 GMT
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.


On Mon, Mar 8, 2010 at 4:28 PM, Anne Kathrine Petter√łe
<> 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 <> 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 <>
>>>> 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 <> wrote:
>>>>> 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 to
>>>>> 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 <>
>>>>>> 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
>>>>>> but are mostly improvements rather than bug fixes. When do we cut
>>>>>> next RC and when we do declare a real release (1.0).
>>>>>> On Sun, Mar 7, 2010 at 6:33 PM, Ethan Jewett <>
>>>>>>> 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
>>>>>>> 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,
>>>>>>> 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
>>>>>>> the RC1 release, I think we should move them to release 1.1 as
>>>>>>> Ethan
>>>>>>> On Tue, Mar 2, 2010 at 9:31 AM, Ethan Jewett <>
>>>>>>>> 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
>>>>>>>> <> wrote:
>>>>>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <>
>>>>>>>>>> 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
>>>>>>>>> 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 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 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
>>>>>>>>>> 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:

View raw message