esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Kathrine Petter√łe <yoji...@gmail.com>
Subject Re: Release 1.0-RC2 in Jira
Date Mon, 08 Mar 2010 21:28:40 GMT
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> 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 <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 bugs
>>>>> but are mostly improvements rather than bug fixes. When do we cut the
>>>>> 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>
wrote:
>>>>>> 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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 


Mime
View raw message