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. Ethan On Mon, Mar 8, 2010 at 4:28 PM, Anne Kathrine Petterøe <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > >
