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 Tue, 02 Mar 2010 15:31:08 GMT
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