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 <[email protected]> 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 <[email protected]> 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 >> <[email protected]> wrote: >>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <[email protected]> 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 - >>> gene...@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 >>> >> >
