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 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >>
