I've discovered a bunch of cool features in maven to help in cutting releases. I can't wait to try them out.
D. On Thu, Mar 11, 2010 at 3:53 PM, Ethan Jewett <[email protected]> wrote: > Ok, I've set the issue to "Fixed". The Release 1.0-RC2 roadmap now > looks nice and green :-) - > > https://issues.apache.org/jira/browse/ESME?report=com.atlassian.jira.plugin.system.project:roadmap-panel > > Ethan > > On Thu, Mar 11, 2010 at 9:49 AM, Richard Hirsch <[email protected]> > wrote: > > This is closed > > > > On Thu, Mar 11, 2010 at 3:46 PM, Ethan Jewett <[email protected]> > wrote: > > > >> 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 > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>> > >> >>>>>> > >> >>>>> > >> >>>> > >> >>> > >> > > >> > > >> > > >
