Well you being Mr. BPX and all...it is extremely funny to hear you say: "I can't wait to try them out" in reference to Maven features ROFL
On 11. mars 2010, at 16.04, Richard Hirsch wrote: > 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >>
