ROFL - I was going to write exactly that but I thought "man - that is really embarrassing - I'd better not write that"
D. On Thu, Mar 11, 2010 at 4:01 PM, Anne Kathrine Petterøe <[email protected]>wrote: > You are sooooooooo turning into a geek :-> > > > On 11. mars 2010, at 16.00, Richard Hirsch wrote: > > > 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 > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>> > >> > >
