incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Re: Release 1.0-RC2 in Jira
Date Mon, 08 Mar 2010 17:28:44 GMT
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