Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

I created a new release in JIRA and started assigning issues to it.

If anyone else has any features or bugs tro fix, then please add this
info to JIRA

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310850&fixfor=12314801

D.

Re: Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

On Mon, Mar 1, 2010 at 9:36 AM, Anne Kathrine Petterøe
<yo...@gmail.com> wrote:
> Ginaugo,
>
> Just to make sure I understand this correctly.
> When we create RCs from the tagged point release (like in this case RC1 from the 1.0 tagged release), we need to go through the voting process each time?

The RC1 is the tagged release. We don't have a 1.0 tagged release.

>
> - anne
>
>
> On 1. mars 2010, at 09.32, Gianugo Rabellino wrote:
>
>> On Thu, Feb 25, 2010 at 3:19 PM, Ethan Jewett <es...@gmail.com> wrote:
>>> I would not put the letters "RC" into an actual Apache release. In my
>>> mind, there is only one release. Release Candidates (RCs) are test
>>> releases that are floated to the group to enable thorough testing and
>>> review, but they are *not* Apache releases. (I welcome being corrected
>>> by mentors and people who know better than me here. :-)
>>
>> Don't get carried away by the apparent clash in a "release" being
>> actually a "candidate": one thing is what constitutes an Apache
>> release (that is the community taking responsibility and producing a
>> public artifact - sort of going on the record, if you like), quite
>> another is the intended scope and audience. Alphas, betas, RCs and
>> whatnot are still releases as they need to follow the Apache release
>> process: as a mentor, I'm expecting this community to understand how
>> the release process always has to dot every i and cross every t when
>> it comes the legal and process bits, while the technical part is left
>> to you guys - my suggestion to use a RC naming scheme basically means
>> that the technical/QA bar might be lower than when it comes to telling
>> your user base you reached the status of golden master.
>>
>> Ciao,
>>
>> --
>> Gianugo Rabellino
>> M: +44 779 5364 932 / +39 389 44 26 846
>> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>
>

Re: Release 1.0-RC2 in Jira

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Mon, Mar 1, 2010 at 9:36 AM, Anne Kathrine Petterøe
<yo...@gmail.com> wrote:
> Just to make sure I understand this correctly.
> When we create RCs from the tagged point release (like in this case RC1 from
> the 1.0 tagged release), we need to go through the voting process each time?...

If the goal is to distribute the result as a release, yes.

According to http://apache.org/dev/release.html a release is "anything
that is published beyond the group that owns it" - so if the goal is
just to create an SVN tag for the ESME community to decide if it's
technically fit as a release candidate, nothing formal is needed.

-Bertrand

Re: Release 1.0-RC2 in Jira

[Anne Kathrine Petterøe <yo...@gmail.com>]

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
> <yo...@gmail.com>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 <es...@gmail.com>
>> 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 <hi...@gmail.com>
>>>> wrote:
>>>>> This is closed
>>>>> 
>>>>> On Thu, Mar 11, 2010 at 3:46 PM, Ethan Jewett <es...@gmail.com>
>>>> 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
>>>>>> <yo...@gmail.com> 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 <es...@gmail.com>
>>>>>> 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 <
>>>> hirsch.dick@gmail.com>
>>>>>> 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 <es...@gmail.com>
>>>>>> 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 <
>>>>>> hirsch.dick@gmail.com> 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 <
>> esjewett@gmail.com
>>>>> 
>>>>>> 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 <
>>>> esjewett@gmail.com>
>>>>>> 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
>>>>>>>>>>>>>> <g....@sourcesense.com> wrote:
>>>>>>>>>>>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <
>>>> esjewett@gmail.com>
>>>>>> 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 -
>>>>>>>>>>>>>>> general@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
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 

Re: Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

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
<yo...@gmail.com>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 <es...@gmail.com>
> 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 <hi...@gmail.com>
> >> wrote:
> >>> This is closed
> >>>
> >>> On Thu, Mar 11, 2010 at 3:46 PM, Ethan Jewett <es...@gmail.com>
> >> 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
> >>>> <yo...@gmail.com> 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 <es...@gmail.com>
> >>>> 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 <
> >> hirsch.dick@gmail.com>
> >>>> 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 <es...@gmail.com>
> >>>> 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 <
> >>>> hirsch.dick@gmail.com> 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 <
> esjewett@gmail.com
> >>>
> >>>> 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 <
> >> esjewett@gmail.com>
> >>>> 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
> >>>>>>>>>>>> <g....@sourcesense.com> wrote:
> >>>>>>>>>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <
> >> esjewett@gmail.com>
> >>>> 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 -
> >>>>>>>>>>>>> general@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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

Re: Release 1.0-RC2 in Jira

[Anne Kathrine Petterøe <yo...@gmail.com>]

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 <es...@gmail.com> 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 <hi...@gmail.com>
>> wrote:
>>> This is closed
>>> 
>>> On Thu, Mar 11, 2010 at 3:46 PM, Ethan Jewett <es...@gmail.com>
>> 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
>>>> <yo...@gmail.com> 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 <es...@gmail.com>
>>>> 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 <
>> hirsch.dick@gmail.com>
>>>> 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 <es...@gmail.com>
>>>> 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 <
>>>> hirsch.dick@gmail.com> 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 <esjewett@gmail.com
>>> 
>>>> 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 <
>> esjewett@gmail.com>
>>>> 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
>>>>>>>>>>>> <g....@sourcesense.com> wrote:
>>>>>>>>>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <
>> esjewett@gmail.com>
>>>> 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 -
>>>>>>>>>>>>> general@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
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Re: Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

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 <es...@gmail.com> 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 <hi...@gmail.com>
> wrote:
> > This is closed
> >
> > On Thu, Mar 11, 2010 at 3:46 PM, Ethan Jewett <es...@gmail.com>
> 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
> >> <yo...@gmail.com> 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 <es...@gmail.com>
> >> 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 <
> hirsch.dick@gmail.com>
> >> 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 <es...@gmail.com>
> >> 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 <
> >> hirsch.dick@gmail.com> 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 <esjewett@gmail.com
> >
> >> 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 <
> esjewett@gmail.com>
> >> 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
> >> >>>>>>>> <g....@sourcesense.com> wrote:
> >> >>>>>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <
> esjewett@gmail.com>
> >> 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 -
> >> >>>>>>>>> general@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
> >> >>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >
> >> >
> >>
> >
>

Re: Release 1.0-RC2 in Jira

[Ethan Jewett <es...@gmail.com>]

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 <hi...@gmail.com> wrote:
> This is closed
>
> On Thu, Mar 11, 2010 at 3:46 PM, Ethan Jewett <es...@gmail.com> 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
>> <yo...@gmail.com> 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 <es...@gmail.com>
>> 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 <hi...@gmail.com>
>> 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 <es...@gmail.com>
>> 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 <
>> hirsch.dick@gmail.com> 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 <es...@gmail.com>
>> 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 <es...@gmail.com>
>> 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
>> >>>>>>>> <g....@sourcesense.com> wrote:
>> >>>>>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com>
>> 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 -
>> >>>>>>>>> general@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
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >
>> >
>>
>

Re: Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

This is closed

On Thu, Mar 11, 2010 at 3:46 PM, Ethan Jewett <es...@gmail.com> 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
> <yo...@gmail.com> 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 <es...@gmail.com>
> 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 <hi...@gmail.com>
> 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 <es...@gmail.com>
> 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 <
> hirsch.dick@gmail.com> 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 <es...@gmail.com>
> 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 <es...@gmail.com>
> 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
> >>>>>>>> <g....@sourcesense.com> wrote:
> >>>>>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com>
> 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 -
> >>>>>>>>> general@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
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
> >
>

Re: Release 1.0-RC2 in Jira

[Ethan Jewett <es...@gmail.com>]

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
<yo...@gmail.com> 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 <es...@gmail.com> 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 <hi...@gmail.com> 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 <es...@gmail.com> 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 <hi...@gmail.com> 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 <es...@gmail.com> 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 <es...@gmail.com> 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
>>>>>>>> <g....@sourcesense.com> wrote:
>>>>>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com> 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 -
>>>>>>>>> general@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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>

Re: Release 1.0-RC2 in Jira

[Anne Kathrine Petterøe <yo...@gmail.com>]

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 <es...@gmail.com> 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 <hi...@gmail.com> 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 <es...@gmail.com> 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 <hi...@gmail.com> 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 <es...@gmail.com> 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 <es...@gmail.com> 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
>>>>>>> <g....@sourcesense.com> wrote:
>>>>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com> 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 -
>>>>>>>> general@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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Re: Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

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 <es...@gmail.com> 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 <hi...@gmail.com> 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 <es...@gmail.com> 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 <hi...@gmail.com> 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 <es...@gmail.com> 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 <es...@gmail.com> 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
>>>>>> <g....@sourcesense.com> wrote:
>>>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com> 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 -
>>>>>>> general@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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Release 1.0-RC2 in Jira

[Ethan Jewett <es...@gmail.com>]

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 <hi...@gmail.com> 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 <es...@gmail.com> 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 <hi...@gmail.com> 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 <es...@gmail.com> 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 <es...@gmail.com> 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
>>>>> <g....@sourcesense.com> wrote:
>>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com> 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 -
>>>>>> general@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
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

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 <es...@gmail.com> 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 <hi...@gmail.com> 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 <es...@gmail.com> 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 <es...@gmail.com> 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
>>>> <g....@sourcesense.com> wrote:
>>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com> 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 -
>>>>> general@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
>>>>>
>>>>
>>>
>>
>

Re: Release 1.0-RC2 in Jira

[Ethan Jewett <es...@gmail.com>]

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 <hi...@gmail.com> 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 <es...@gmail.com> 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 <es...@gmail.com> 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
>>> <g....@sourcesense.com> wrote:
>>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com> 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 -
>>>> general@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
>>>>
>>>
>>
>

Re: Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

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 <es...@gmail.com> 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 <es...@gmail.com> 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
>> <g....@sourcesense.com> wrote:
>>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com> 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 -
>>> general@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
>>>
>>
>

Re: Release 1.0-RC2 in Jira

[Ethan Jewett <es...@gmail.com>]

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 <es...@gmail.com> 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
> <g....@sourcesense.com> wrote:
>> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com> 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 -
>> general@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
>>
>

Re: Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com> 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.

Agreed but does that mean that just bug fixes are placed in Release-1.0-RCs.?


ESME-100 (finish Web UI) is an example
> of something that should *not* stay in Release-1.0-RC2.

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

But you are forgetting the community aspect of voting.

>
> 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".
>
> Ethan
>
> On Tue, Mar 2, 2010 at 6:19 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> On Tue, Mar 2, 2010 at 9:21 AM, Richard Hirsch <hi...@gmail.com> wrote:
>>> I think there are different definitions of "release" that are confusing things.
>>>
>>> One is a release from the perspective of ASF which is concerned with
>>> the process (votes on the MLs, etc.) and certain legal requirements.
>>> I think Gianugo's last email expresses this focus on this consensus.
>>> What is released (alpha release, beta release, RC, etc.) is here not
>>> the focus....
>>
>> Just to reiterate, according to http://apache.org/dev/release.html a
>> release is "anything that is published beyond the group that owns it",
>> so as soon as a release is made available for download on the ESME
>> website (as opposed to just being mentioned here) it is an Apache
>> release.
>>
>> Even naming it "junk release not to be used" won't make a difference,
>> if it's published it has to be voted on.
>>
>> Naming an SVN tag or internally distributed tarball "release" doesn't
>> make it a release either - it's the act of publishing it beyond the
>> ESME group of developers (this mailing list) that makes a release and
>> requires a vote.
>>
>> -Bertrand
>>
>

Re: Release 1.0-RC2 in Jira

[Ethan Jewett <es...@gmail.com>]

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
<g....@sourcesense.com> wrote:
> On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com> 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 -
> general@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
>

Re: Release 1.0-RC2 in Jira

[Gianugo Rabellino <g....@sourcesense.com>]

On Tue, Mar 2, 2010 at 3:28 PM, Ethan Jewett <es...@gmail.com> 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 -
general@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

Re: Release 1.0-RC2 in Jira

[Ethan Jewett <es...@gmail.com>]

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.

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.

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

Ethan

On Tue, Mar 2, 2010 at 6:19 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Tue, Mar 2, 2010 at 9:21 AM, Richard Hirsch <hi...@gmail.com> wrote:
>> I think there are different definitions of "release" that are confusing things.
>>
>> One is a release from the perspective of ASF which is concerned with
>> the process (votes on the MLs, etc.) and certain legal requirements.
>> I think Gianugo's last email expresses this focus on this consensus.
>> What is released (alpha release, beta release, RC, etc.) is here not
>> the focus....
>
> Just to reiterate, according to http://apache.org/dev/release.html a
> release is "anything that is published beyond the group that owns it",
> so as soon as a release is made available for download on the ESME
> website (as opposed to just being mentioned here) it is an Apache
> release.
>
> Even naming it "junk release not to be used" won't make a difference,
> if it's published it has to be voted on.
>
> Naming an SVN tag or internally distributed tarball "release" doesn't
> make it a release either - it's the act of publishing it beyond the
> ESME group of developers (this mailing list) that makes a release and
> requires a vote.
>
> -Bertrand
>

Re: Release 1.0-RC2 in Jira

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Mar 2, 2010 at 9:21 AM, Richard Hirsch <hi...@gmail.com> wrote:
> I think there are different definitions of "release" that are confusing things.
>
> One is a release from the perspective of ASF which is concerned with
> the process (votes on the MLs, etc.) and certain legal requirements.
> I think Gianugo's last email expresses this focus on this consensus.
> What is released (alpha release, beta release, RC, etc.) is here not
> the focus....

Just to reiterate, according to http://apache.org/dev/release.html a
release is "anything that is published beyond the group that owns it",
so as soon as a release is made available for download on the ESME
website (as opposed to just being mentioned here) it is an Apache
release.

Even naming it "junk release not to be used" won't make a difference,
if it's published it has to be voted on.

Naming an SVN tag or internally distributed tarball "release" doesn't
make it a release either - it's the act of publishing it beyond the
ESME group of developers (this mailing list) that makes a release and
requires a vote.

-Bertrand

Re: Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

I think there are different definitions of "release" that are confusing things.

One is a release from the perspective of ASF which is concerned with
the process (votes on the MLs, etc.) and certain legal requirements.
I think Gianugo's last email expresses this focus on this consensus.
What is released (alpha release, beta release, RC, etc.) is here not
the focus.

The other definition of release is more associated with the
development status of the software in question.

For me, the focus was more on the ASF definition of the release. My
main goal was to use the release to meet the legal requirements
(ESME-47 + other concerns) necessary as well as learn "how to release
code" which is one of the main criterion for becoming a TLP.   I also
see a release as a sign of a project's maturity. Obviously, the
current release isn't perfect - that is one of the reasons why I like
the idea of tagging it as a RC rather than our official release. If
you take a look at the the releases of the other projects in the
incubator, you will also see a variety of release names:
http://www.apache.org/dist/incubator/

D.

On Tue, Mar 2, 2010 at 12:26 AM, Anne Kathrine Petterøe
<yo...@gmail.com> wrote:
> Glad we are having the discussion now, because I also got a bit confused by the RC "acting" like a full Apache release :)
>
> Ethan, I agree with your definition of RC vs full release.
> At this point I cannot see why we should go through a full release process to see if we are ready to make a release. It feels like a slight overkill, at least for the time being when only 3-4 people (afaik) on the dev list use the RC for testing purposes.
>
> - anne
>
>
> On 2. mars 2010, at 00.14, Ethan Jewett wrote:
>
>> How is publishing a tarball on a public site that is clearly labelled
>> as a trial release and *not* for general consumption significantly
>> different than making available a public SVN repository?
>>
>> Ethan
>>
>> On Mon, Mar 1, 2010 at 6:06 PM, Gianugo Rabellino
>> <g....@sourcesense.com> wrote:
>>> On Mon, Mar 1, 2010 at 11:57 PM, Ethan Jewett <es...@gmail.com> wrote:
>>>> If we are cutting a tag into a trial release in order to help
>>>> ourselves figure out if we are ready to make a release, then I think
>>>> we should call it a "release candidate" and we should not go through
>>>> the full Apache release process and we should not "release" it. We
>>>> should just put the RC tarball out on the public site for people to
>>>> evaluate,
>>>
>>> Which at great length fits the ASF definition of a release... :)
>>>
>>> "Releases are, by definition, anything that is published beyond the
>>> group that owns it. In our case, that means any publication outside
>>> the group of people on the product dev list. If the general public is
>>> being instructed to download a package, then that package has been
>>> released." (http://apache.org/dev/release.html)
>>>
>>> --
>>> Gianugo Rabellino
>>> M: +44 779 5364 932 / +39 389 44 26 846
>>> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>>>
>
>

Re: Release 1.0-RC2 in Jira

[Anne Kathrine Petterøe <yo...@gmail.com>]

Glad we are having the discussion now, because I also got a bit confused by the RC "acting" like a full Apache release :)

Ethan, I agree with your definition of RC vs full release.
At this point I cannot see why we should go through a full release process to see if we are ready to make a release. It feels like a slight overkill, at least for the time being when only 3-4 people (afaik) on the dev list use the RC for testing purposes.

- anne


On 2. mars 2010, at 00.14, Ethan Jewett wrote:

> How is publishing a tarball on a public site that is clearly labelled
> as a trial release and *not* for general consumption significantly
> different than making available a public SVN repository?
> 
> Ethan
> 
> On Mon, Mar 1, 2010 at 6:06 PM, Gianugo Rabellino
> <g....@sourcesense.com> wrote:
>> On Mon, Mar 1, 2010 at 11:57 PM, Ethan Jewett <es...@gmail.com> wrote:
>>> If we are cutting a tag into a trial release in order to help
>>> ourselves figure out if we are ready to make a release, then I think
>>> we should call it a "release candidate" and we should not go through
>>> the full Apache release process and we should not "release" it. We
>>> should just put the RC tarball out on the public site for people to
>>> evaluate,
>> 
>> Which at great length fits the ASF definition of a release... :)
>> 
>> "Releases are, by definition, anything that is published beyond the
>> group that owns it. In our case, that means any publication outside
>> the group of people on the product dev list. If the general public is
>> being instructed to download a package, then that package has been
>> released." (http://apache.org/dev/release.html)
>> 
>> --
>> Gianugo Rabellino
>> M: +44 779 5364 932 / +39 389 44 26 846
>> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>> 

Re: Release 1.0-RC2 in Jira

[Gianugo Rabellino <g....@sourcesense.com>]

On Tue, Mar 2, 2010 at 12:14 AM, Ethan Jewett <es...@gmail.com> wrote:
> How is publishing a tarball on a public site that is clearly labelled
> as a trial release and *not* for general consumption significantly
> different than making available a public SVN repository?

Maybe we're getting semantic cross-wires here, but an RC _is_ by
definition for general consumption. Much like alphas and betas, and
actually even more. To me it's something like:

- SVN and nightlies: designed for developers only, might not even compile
- alpha: hey community, care to give it a shot? chances are it will be
full of bugs, but we could use some help. Don't make it even get close
to production systems
- beta: hey public, we are almost ready and this is almost your final
chance to speak up. Give it a spin, please? And yes, bugs are expected
- don't use this in production unless you really know what you're
doing and we are a mile away (two if downwind)
- RCs: ok, unless we screwed something up really seriously, this is
close to golden master. If you are very brave and know your way, you
may actually use it in production, although it's not really a wise
thing to do. So speak up now, or forever hold your peace

In any case, the real difference is that SVN is a perpetually moving
target, with no agreement whatsoever from the community on what a
snapshot means. A release is just that: the developers agree that a
revision of the SVN tree is consistent enough to be packaged - so
there comes your need for explicit consensus.

Don't let the scars from this initial release process scare you too
much. Once the ball is rolling (with no major hiccups such as legal
crap), the release process _is_ lightweight enough and fits the
"release early, release often" bill.

-- 
Gianugo Rabellino
M: +44 779 5364 932 / +39 389 44 26 846
Sourcesense - making sense of Open Source: http://www.sourcesense.com

Re: Release 1.0-RC2 in Jira

[Ethan Jewett <es...@gmail.com>]

How is publishing a tarball on a public site that is clearly labelled
as a trial release and *not* for general consumption significantly
different than making available a public SVN repository?

Ethan

On Mon, Mar 1, 2010 at 6:06 PM, Gianugo Rabellino
<g....@sourcesense.com> wrote:
> On Mon, Mar 1, 2010 at 11:57 PM, Ethan Jewett <es...@gmail.com> wrote:
>> If we are cutting a tag into a trial release in order to help
>> ourselves figure out if we are ready to make a release, then I think
>> we should call it a "release candidate" and we should not go through
>> the full Apache release process and we should not "release" it. We
>> should just put the RC tarball out on the public site for people to
>> evaluate,
>
> Which at great length fits the ASF definition of a release... :)
>
> "Releases are, by definition, anything that is published beyond the
> group that owns it. In our case, that means any publication outside
> the group of people on the product dev list. If the general public is
> being instructed to download a package, then that package has been
> released." (http://apache.org/dev/release.html)
>
> --
> Gianugo Rabellino
> M: +44 779 5364 932 / +39 389 44 26 846
> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>

Re: Release 1.0-RC2 in Jira

[Gianugo Rabellino <g....@sourcesense.com>]

On Mon, Mar 1, 2010 at 11:57 PM, Ethan Jewett <es...@gmail.com> wrote:
> If we are cutting a tag into a trial release in order to help
> ourselves figure out if we are ready to make a release, then I think
> we should call it a "release candidate" and we should not go through
> the full Apache release process and we should not "release" it. We
> should just put the RC tarball out on the public site for people to
> evaluate,

Which at great length fits the ASF definition of a release... :)

"Releases are, by definition, anything that is published beyond the
group that owns it. In our case, that means any publication outside
the group of people on the product dev list. If the general public is
being instructed to download a package, then that package has been
released." (http://apache.org/dev/release.html)

-- 
Gianugo Rabellino
M: +44 779 5364 932 / +39 389 44 26 846
Sourcesense - making sense of Open Source: http://www.sourcesense.com

Re: Release 1.0-RC2 in Jira

[Ethan Jewett <es...@gmail.com>]

I don't think there really was an RC vs. point-release discussion.
That's what we're having right now, in addition to the rest of the
process discussion ;-)

My view is that we should not, as a rule, call a full Apache release a
"Release Candidate". I know it's just semantics, but I think it's
going to confuse the heck out of people (as it did me).

If we think that a release is ready to be deployed into production
environments by our users, then I think we should give it a
point-release name and we should go through the Apache release process
with it.

If we are cutting a tag into a trial release in order to help
ourselves figure out if we are ready to make a release, then I think
we should call it a "release candidate" and we should not go through
the full Apache release process and we should not "release" it. We
should just put the RC tarball out on the public site for people to
evaluate, and maybe do a vote on this list to determine if we have
consensus that we are ready to attempt a full release.

Of course, my view has extremely limited weight since I'm not doing
any of the actual release work!

Ethan

On Mon, Mar 1, 2010 at 3:49 AM, Anne Kathrine Petterøe
<yo...@gmail.com> wrote:
> Thanks everyone for clarifying.
>
> Maybe it was just me, but I wasn't aware that we were going to release the RCs for distribution, hence my confusion about all the current voting rounds we are going through.
> I thought the RCs were just intended for the ESME community to do smoke/stress tests before the actual release and that we would have a formal vote when we agreed that an RC is technically fit for a release.
> But I have been a bit busy at work these days, so I guess I just missed the RC vs point-release discussion on the list, my bad.
>
> - anne
>
>
> On 1. mars 2010, at 09.41, Gianugo Rabellino wrote:
>
>> On Mon, Mar 1, 2010 at 9:36 AM, Anne Kathrine Petterøe
>> <yo...@gmail.com> wrote:
>>> Ginaugo,
>>>
>>> Just to make sure I understand this correctly.
>>> When we create RCs from the tagged point release (like in this case RC1 from the 1.0 tagged release), we need to go through the voting process each time?
>>
>> You have to vote when you _release_ anything, that is you make
>> available to the general public an artifact via the ASF distribution
>> channel. You may call it as you wish, and the way you deal with SVN
>> tags has nothing to do with it. :-)
>>
>> --
>> Gianugo Rabellino
>> M: +44 779 5364 932 / +39 389 44 26 846
>> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>
>

Re: Release 1.0-RC2 in Jira

[Anne Kathrine Petterøe <yo...@gmail.com>]

Thanks everyone for clarifying.

Maybe it was just me, but I wasn't aware that we were going to release the RCs for distribution, hence my confusion about all the current voting rounds we are going through. 
I thought the RCs were just intended for the ESME community to do smoke/stress tests before the actual release and that we would have a formal vote when we agreed that an RC is technically fit for a release. 
But I have been a bit busy at work these days, so I guess I just missed the RC vs point-release discussion on the list, my bad.

- anne


On 1. mars 2010, at 09.41, Gianugo Rabellino wrote:

> On Mon, Mar 1, 2010 at 9:36 AM, Anne Kathrine Petterøe
> <yo...@gmail.com> wrote:
>> Ginaugo,
>> 
>> Just to make sure I understand this correctly.
>> When we create RCs from the tagged point release (like in this case RC1 from the 1.0 tagged release), we need to go through the voting process each time?
> 
> You have to vote when you _release_ anything, that is you make
> available to the general public an artifact via the ASF distribution
> channel. You may call it as you wish, and the way you deal with SVN
> tags has nothing to do with it. :-)
> 
> -- 
> Gianugo Rabellino
> M: +44 779 5364 932 / +39 389 44 26 846
> Sourcesense - making sense of Open Source: http://www.sourcesense.com

Re: Release 1.0-RC2 in Jira

[Gianugo Rabellino <g....@sourcesense.com>]

On Mon, Mar 1, 2010 at 9:36 AM, Anne Kathrine Petterøe
<yo...@gmail.com> wrote:
> Ginaugo,
>
> Just to make sure I understand this correctly.
> When we create RCs from the tagged point release (like in this case RC1 from the 1.0 tagged release), we need to go through the voting process each time?

You have to vote when you _release_ anything, that is you make
available to the general public an artifact via the ASF distribution
channel. You may call it as you wish, and the way you deal with SVN
tags has nothing to do with it. :-)

-- 
Gianugo Rabellino
M: +44 779 5364 932 / +39 389 44 26 846
Sourcesense - making sense of Open Source: http://www.sourcesense.com

Re: Release 1.0-RC2 in Jira

[Anne Kathrine Petterøe <yo...@gmail.com>]

Ginaugo,

Just to make sure I understand this correctly.
When we create RCs from the tagged point release (like in this case RC1 from the 1.0 tagged release), we need to go through the voting process each time?

- anne


On 1. mars 2010, at 09.32, Gianugo Rabellino wrote:

> On Thu, Feb 25, 2010 at 3:19 PM, Ethan Jewett <es...@gmail.com> wrote:
>> I would not put the letters "RC" into an actual Apache release. In my
>> mind, there is only one release. Release Candidates (RCs) are test
>> releases that are floated to the group to enable thorough testing and
>> review, but they are *not* Apache releases. (I welcome being corrected
>> by mentors and people who know better than me here. :-)
> 
> Don't get carried away by the apparent clash in a "release" being
> actually a "candidate": one thing is what constitutes an Apache
> release (that is the community taking responsibility and producing a
> public artifact - sort of going on the record, if you like), quite
> another is the intended scope and audience. Alphas, betas, RCs and
> whatnot are still releases as they need to follow the Apache release
> process: as a mentor, I'm expecting this community to understand how
> the release process always has to dot every i and cross every t when
> it comes the legal and process bits, while the technical part is left
> to you guys - my suggestion to use a RC naming scheme basically means
> that the technical/QA bar might be lower than when it comes to telling
> your user base you reached the status of golden master.
> 
> Ciao,
> 
> -- 
> Gianugo Rabellino
> M: +44 779 5364 932 / +39 389 44 26 846
> Sourcesense - making sense of Open Source: http://www.sourcesense.com

Re: Release 1.0-RC2 in Jira

[Gianugo Rabellino <g....@sourcesense.com>]

On Thu, Feb 25, 2010 at 3:19 PM, Ethan Jewett <es...@gmail.com> wrote:
> I would not put the letters "RC" into an actual Apache release. In my
> mind, there is only one release. Release Candidates (RCs) are test
> releases that are floated to the group to enable thorough testing and
> review, but they are *not* Apache releases. (I welcome being corrected
> by mentors and people who know better than me here. :-)

Don't get carried away by the apparent clash in a "release" being
actually a "candidate": one thing is what constitutes an Apache
release (that is the community taking responsibility and producing a
public artifact - sort of going on the record, if you like), quite
another is the intended scope and audience. Alphas, betas, RCs and
whatnot are still releases as they need to follow the Apache release
process: as a mentor, I'm expecting this community to understand how
the release process always has to dot every i and cross every t when
it comes the legal and process bits, while the technical part is left
to you guys - my suggestion to use a RC naming scheme basically means
that the technical/QA bar might be lower than when it comes to telling
your user base you reached the status of golden master.

Ciao,

-- 
Gianugo Rabellino
M: +44 779 5364 932 / +39 389 44 26 846
Sourcesense - making sense of Open Source: http://www.sourcesense.com

Re: Release 1.0-RC2 in Jira

[Anne Kathrine Petterøe <yo...@gmail.com>]

Thanks for starting this discussion Ethan.
I have actually been doing some thinking around this as well, mostly because I felt that voting for every RC and then the release itself might be a bit overkill. Release candidates should be for testing purposes only. If we vote on a release candidate (like we just did), then that RC will be the point-release.

I think your suggestion here is great and I am all for it:
Frozen JIRA release: 1.0
Release strategy: Frozen in a tag from trunk, then updates are made to
both tag and trunk and release candidates (1.0-RC1, 1.0-RC2) are cut
directly from the tag. If there are release-blocking issues with an
RC, then that ticket should go into the JIRA release that the RC was
cut from (1.0 in this case). Otherwise the issue should go into the
backlog. 

- anne
 
On 25. feb. 2010, at 15.19, Ethan Jewett wrote:

> I'll just respond now, since I think we just have a misunderstanding.
> Again, this is just my opinion and understanding. I have been known to
> be wrong before. ;-)
> 
> On Wed, Feb 24, 2010 at 4:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
>> Excellent points.....
>> 
>> On Wed, Feb 24, 2010 at 4:13 PM, Ethan Jewett <es...@gmail.com> wrote:
>>> Hi all,
>>> 
>>> I must admit that I don't understand the approach here. I meant to
>>> bring this up separately after the release, rather than as a negative
>>> reaction, but I didn't move fast enough :-) In that light, please take
>>> this as an alternative suggestion, based on how I understand the
>>> inter-relation of releases and release candidates (RCs). I'm very very
>>> open to considering other options, but I think we need to have the
>>> discussion about how our release strategy works.
>> 
>> I admit I created the new RC in JIRA without really thinking about
>> whether we want to continue working from the tagged branch or not.  I
>> have no problem working on the tagged branch. I'm assuming that most
>> activity will take place there. But do you really think that there
>> will be very much activity on the trunk?
>> 
>> At this point, I'm trying to keep things as easy / simple as possible.
>> I'm hoping that there won't be any need to commit any changes to the
>> RC1.  To be truthful, I'd rather make the code changes in RC2 and tell
>> people to use the newer RC. Once we get farther along and a variety of
>> customers are using ESME,  then things will be a different story.
> 
> What are we planning to call the current release we are working on? I
> think this is where we are misunderstanding each other.
> 
> I would not put the letters "RC" into an actual Apache release. In my
> mind, there is only one release. Release Candidates (RCs) are test
> releases that are floated to the group to enable thorough testing and
> review, but they are *not* Apache releases. (I welcome being corrected
> by mentors and people who know better than me here. :-)
> 
> I suggest that when the group actually votes to do the release with a
> given RC, that RC (exactly and without change) is released as whatever
> point-release we are attempting. (Bigger projects have release
> schedules and specific numbers of RCs before attempting the actual
> release, but I don't think we need to do that at this point.)
> 
> Because of this, I think the pom.xml of a release candidate should
> probably specify the final release version we are targeting, rather
> than an RC release version. That way we can just release the RC
> directly rather than having to do another release vote with an updated
> pom.xml.
> 
> I'd just go through with this release, but I think we need to get this
> straightened out for the future.
> 
>> 
>> 
>>> 
>>> Here's my take:
>>> 
>>> Frozen JIRA release: 1.0
>>> Release strategy: Frozen in a tag from trunk, then updates are made to
>>> both tag and trunk and release candidates (1.0-RC1, 1.0-RC2) are cut
>>> directly from the tag. If there are release-blocking issues with an
>>> RC, then that ticket should go into the JIRA release that the RC was
>>> cut from (1.0 in this case). Otherwise the issue should go into the
>>> backlog. I realize we haven't been doing this for this release, but
>>> effectively we have because the only activity on trunk have been
>>> updates that are going into the release.
>> 
>> Is the release 1.0 really clearly defined that we can say what goes
>> there and what goes into 1.1.
> 
> I thought we were attempting to do release 1.0 right now. We had
> several discussions about what JIRA items were included in release 1.0
> and we ended up dropping the new UI from scope along with a bunch of
> other stuff. So yes, I think release 1.0 is pretty well defined.
> 
> Everything else, in my mind, should go into a subsequent release (not
> a subsequent RC - RCs are just test versions of a release, so an RC
> for the 1.0 release should not include any functionality not included
> in the 1.0 release).
> 
>> 
>>> 
>>> Working JIRA release (next release): 1.1?
>>> Release strategy: We should have a discussion about what open JIRA
>>> tickets should be targeted for this release, then move their "Fix
>>> Release" to this release. If we decide we want to add features that
>>> aren't set up as JIRA tickets, then we should have that discussion and
>>> create tickets for them.
>> 
>> I don't know whether we really have a 1.1 yet. I'm assuming that most
>> everything will go towards the 1.0 release.  Maybe we need a JIRA tag
>> for 1.1.
> 
> We can name our next target release without having locked down scope.
> That's all I was suggesting with "1.1". Having the release number out
> there in JIRA allows us to use the JIRA tool to manage release scope.
> 
>> 
>>> 
>>> Backlog JIRA release: Backlog (or Unassigned)
>>> Release strategy: All new issues (bugs and feature requests) should go
>>> into this release in JIRA. Issues can be moved from the backlog into a
>>> specific release, but it should be based on some sort of consensus, or
>>> be open to veto.
>> 
>> Agreed. That is why I started this thread - to get the conversation started.
>> 
>> Developers should be encouraged to work on the issues
>>> in the backlog as they are able, but I'd think the core team would
>>> focus mostly on issues assigned to the next release (recognizing, of
>>> course, that this is a classic open source "scratch your own itch"
>>> situation and people will work on whatever they want). If an issue is
>>> fixed while it is in the backlog, then the resolved ticket should be
>>> moved into the current working release (1.1 in this case) so that it
>>> is picked up in the release notes.
>> 
>> But where should developers commit their code from backlog issues? In
>> the trunk?
> 
> Yes, trunk (in my opinion) should track the most up to date code base.
> Trunk keeps going even when we have locked a release using a tag.
> Really big projects have to do all kinds of stuff with locking trunk
> or having multiple trunks for different major versions, but I don't
> think we have to worry about any of that at the moment.
> 
> Ethan

Re: Release 1.0-RC2 in Jira

[Ethan Jewett <es...@gmail.com>]

I'll just respond now, since I think we just have a misunderstanding.
Again, this is just my opinion and understanding. I have been known to
be wrong before. ;-)

On Wed, Feb 24, 2010 at 4:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
> Excellent points.....
>
> On Wed, Feb 24, 2010 at 4:13 PM, Ethan Jewett <es...@gmail.com> wrote:
>> Hi all,
>>
>> I must admit that I don't understand the approach here. I meant to
>> bring this up separately after the release, rather than as a negative
>> reaction, but I didn't move fast enough :-) In that light, please take
>> this as an alternative suggestion, based on how I understand the
>> inter-relation of releases and release candidates (RCs). I'm very very
>> open to considering other options, but I think we need to have the
>> discussion about how our release strategy works.
>
> I admit I created the new RC in JIRA without really thinking about
> whether we want to continue working from the tagged branch or not.  I
> have no problem working on the tagged branch. I'm assuming that most
> activity will take place there. But do you really think that there
> will be very much activity on the trunk?
>
> At this point, I'm trying to keep things as easy / simple as possible.
> I'm hoping that there won't be any need to commit any changes to the
> RC1.  To be truthful, I'd rather make the code changes in RC2 and tell
> people to use the newer RC. Once we get farther along and a variety of
> customers are using ESME,  then things will be a different story.

What are we planning to call the current release we are working on? I
think this is where we are misunderstanding each other.

I would not put the letters "RC" into an actual Apache release. In my
mind, there is only one release. Release Candidates (RCs) are test
releases that are floated to the group to enable thorough testing and
review, but they are *not* Apache releases. (I welcome being corrected
by mentors and people who know better than me here. :-)

I suggest that when the group actually votes to do the release with a
given RC, that RC (exactly and without change) is released as whatever
point-release we are attempting. (Bigger projects have release
schedules and specific numbers of RCs before attempting the actual
release, but I don't think we need to do that at this point.)

Because of this, I think the pom.xml of a release candidate should
probably specify the final release version we are targeting, rather
than an RC release version. That way we can just release the RC
directly rather than having to do another release vote with an updated
pom.xml.

I'd just go through with this release, but I think we need to get this
straightened out for the future.

>
>
>>
>> Here's my take:
>>
>> Frozen JIRA release: 1.0
>> Release strategy: Frozen in a tag from trunk, then updates are made to
>> both tag and trunk and release candidates (1.0-RC1, 1.0-RC2) are cut
>> directly from the tag. If there are release-blocking issues with an
>> RC, then that ticket should go into the JIRA release that the RC was
>> cut from (1.0 in this case). Otherwise the issue should go into the
>> backlog. I realize we haven't been doing this for this release, but
>> effectively we have because the only activity on trunk have been
>> updates that are going into the release.
>
> Is the release 1.0 really clearly defined that we can say what goes
> there and what goes into 1.1.

I thought we were attempting to do release 1.0 right now. We had
several discussions about what JIRA items were included in release 1.0
and we ended up dropping the new UI from scope along with a bunch of
other stuff. So yes, I think release 1.0 is pretty well defined.

Everything else, in my mind, should go into a subsequent release (not
a subsequent RC - RCs are just test versions of a release, so an RC
for the 1.0 release should not include any functionality not included
in the 1.0 release).

>
>>
>> Working JIRA release (next release): 1.1?
>> Release strategy: We should have a discussion about what open JIRA
>> tickets should be targeted for this release, then move their "Fix
>> Release" to this release. If we decide we want to add features that
>> aren't set up as JIRA tickets, then we should have that discussion and
>> create tickets for them.
>
> I don't know whether we really have a 1.1 yet. I'm assuming that most
> everything will go towards the 1.0 release.  Maybe we need a JIRA tag
> for 1.1.

We can name our next target release without having locked down scope.
That's all I was suggesting with "1.1". Having the release number out
there in JIRA allows us to use the JIRA tool to manage release scope.

>
>>
>> Backlog JIRA release: Backlog (or Unassigned)
>> Release strategy: All new issues (bugs and feature requests) should go
>> into this release in JIRA. Issues can be moved from the backlog into a
>> specific release, but it should be based on some sort of consensus, or
>> be open to veto.
>
> Agreed. That is why I started this thread - to get the conversation started.
>
> Developers should be encouraged to work on the issues
>> in the backlog as they are able, but I'd think the core team would
>> focus mostly on issues assigned to the next release (recognizing, of
>> course, that this is a classic open source "scratch your own itch"
>> situation and people will work on whatever they want). If an issue is
>> fixed while it is in the backlog, then the resolved ticket should be
>> moved into the current working release (1.1 in this case) so that it
>> is picked up in the release notes.
>
> But where should developers commit their code from backlog issues? In
> the trunk?

Yes, trunk (in my opinion) should track the most up to date code base.
Trunk keeps going even when we have locked a release using a tag.
Really big projects have to do all kinds of stuff with locking trunk
or having multiple trunks for different major versions, but I don't
think we have to worry about any of that at the moment.

Ethan

Re: Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

I'd suggest fixing major bugs (like
http://issues.apache.org/jira/browse/ESME-162) in the RC1 branch and
putting new functionality in the trunk.

D.

On Wed, Feb 24, 2010 at 10:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
> Excellent points.....
>
> On Wed, Feb 24, 2010 at 4:13 PM, Ethan Jewett <es...@gmail.com> wrote:
>> Hi all,
>>
>> I must admit that I don't understand the approach here. I meant to
>> bring this up separately after the release, rather than as a negative
>> reaction, but I didn't move fast enough :-) In that light, please take
>> this as an alternative suggestion, based on how I understand the
>> inter-relation of releases and release candidates (RCs). I'm very very
>> open to considering other options, but I think we need to have the
>> discussion about how our release strategy works.
>
> I admit I created the new RC in JIRA without really thinking about
> whether we want to continue working from the tagged branch or not.  I
> have no problem working on the tagged branch. I'm assuming that most
> activity will take place there. But do you really think that there
> will be very much activity on the trunk?
>
> At this point, I'm trying to keep things as easy / simple as possible.
> I'm hoping that there won't be any need to commit any changes to the
> RC1.  To be truthful, I'd rather make the code changes in RC2 and tell
> people to use the newer RC. Once we get farther along and a variety of
> customers are using ESME,  then things will be a different story.
>
>
>>
>> Here's my take:
>>
>> Frozen JIRA release: 1.0
>> Release strategy: Frozen in a tag from trunk, then updates are made to
>> both tag and trunk and release candidates (1.0-RC1, 1.0-RC2) are cut
>> directly from the tag. If there are release-blocking issues with an
>> RC, then that ticket should go into the JIRA release that the RC was
>> cut from (1.0 in this case). Otherwise the issue should go into the
>> backlog. I realize we haven't been doing this for this release, but
>> effectively we have because the only activity on trunk have been
>> updates that are going into the release.
>
> Is the release 1.0 really clearly defined that we can say what goes
> there and what goes into 1.1.
>
>>
>> Working JIRA release (next release): 1.1?
>> Release strategy: We should have a discussion about what open JIRA
>> tickets should be targeted for this release, then move their "Fix
>> Release" to this release. If we decide we want to add features that
>> aren't set up as JIRA tickets, then we should have that discussion and
>> create tickets for them.
>
> I don't know whether we really have a 1.1 yet. I'm assuming that most
> everything will go towards the 1.0 release.  Maybe we need a JIRA tag
> for 1.1.
>
>>
>> Backlog JIRA release: Backlog (or Unassigned)
>> Release strategy: All new issues (bugs and feature requests) should go
>> into this release in JIRA. Issues can be moved from the backlog into a
>> specific release, but it should be based on some sort of consensus, or
>> be open to veto.
>
> Agreed. That is why I started this thread - to get the conversation started.
>
> Developers should be encouraged to work on the issues
>> in the backlog as they are able, but I'd think the core team would
>> focus mostly on issues assigned to the next release (recognizing, of
>> course, that this is a classic open source "scratch your own itch"
>> situation and people will work on whatever they want). If an issue is
>> fixed while it is in the backlog, then the resolved ticket should be
>> moved into the current working release (1.1 in this case) so that it
>> is picked up in the release notes.
>
> But where should developers commit their code from backlog issues? In
> the trunk?
>
>>
>> Thoughts?
>>
>> Ethan
>>
>> On Tue, Feb 23, 2010 at 11:54 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>> I created a new release in JIRA and started assigning issues to it.
>>>
>>> If anyone else has any features or bugs tro fix, then please add this
>>> info to JIRA
>>>
>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310850&fixfor=12314801
>>>
>>> D.
>>>
>>
>

Re: Release 1.0-RC2 in Jira

[Richard Hirsch <hi...@gmail.com>]

Excellent points.....

On Wed, Feb 24, 2010 at 4:13 PM, Ethan Jewett <es...@gmail.com> wrote:
> Hi all,
>
> I must admit that I don't understand the approach here. I meant to
> bring this up separately after the release, rather than as a negative
> reaction, but I didn't move fast enough :-) In that light, please take
> this as an alternative suggestion, based on how I understand the
> inter-relation of releases and release candidates (RCs). I'm very very
> open to considering other options, but I think we need to have the
> discussion about how our release strategy works.

I admit I created the new RC in JIRA without really thinking about
whether we want to continue working from the tagged branch or not.  I
have no problem working on the tagged branch. I'm assuming that most
activity will take place there. But do you really think that there
will be very much activity on the trunk?

At this point, I'm trying to keep things as easy / simple as possible.
I'm hoping that there won't be any need to commit any changes to the
RC1.  To be truthful, I'd rather make the code changes in RC2 and tell
people to use the newer RC. Once we get farther along and a variety of
customers are using ESME,  then things will be a different story.


>
> Here's my take:
>
> Frozen JIRA release: 1.0
> Release strategy: Frozen in a tag from trunk, then updates are made to
> both tag and trunk and release candidates (1.0-RC1, 1.0-RC2) are cut
> directly from the tag. If there are release-blocking issues with an
> RC, then that ticket should go into the JIRA release that the RC was
> cut from (1.0 in this case). Otherwise the issue should go into the
> backlog. I realize we haven't been doing this for this release, but
> effectively we have because the only activity on trunk have been
> updates that are going into the release.

Is the release 1.0 really clearly defined that we can say what goes
there and what goes into 1.1.

>
> Working JIRA release (next release): 1.1?
> Release strategy: We should have a discussion about what open JIRA
> tickets should be targeted for this release, then move their "Fix
> Release" to this release. If we decide we want to add features that
> aren't set up as JIRA tickets, then we should have that discussion and
> create tickets for them.

I don't know whether we really have a 1.1 yet. I'm assuming that most
everything will go towards the 1.0 release.  Maybe we need a JIRA tag
for 1.1.

>
> Backlog JIRA release: Backlog (or Unassigned)
> Release strategy: All new issues (bugs and feature requests) should go
> into this release in JIRA. Issues can be moved from the backlog into a
> specific release, but it should be based on some sort of consensus, or
> be open to veto.

Agreed. That is why I started this thread - to get the conversation started.

Developers should be encouraged to work on the issues
> in the backlog as they are able, but I'd think the core team would
> focus mostly on issues assigned to the next release (recognizing, of
> course, that this is a classic open source "scratch your own itch"
> situation and people will work on whatever they want). If an issue is
> fixed while it is in the backlog, then the resolved ticket should be
> moved into the current working release (1.1 in this case) so that it
> is picked up in the release notes.

But where should developers commit their code from backlog issues? In
the trunk?

>
> Thoughts?
>
> Ethan
>
> On Tue, Feb 23, 2010 at 11:54 PM, Richard Hirsch <hi...@gmail.com> wrote:
>> I created a new release in JIRA and started assigning issues to it.
>>
>> If anyone else has any features or bugs tro fix, then please add this
>> info to JIRA
>>
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310850&fixfor=12314801
>>
>> D.
>>
>

Re: Release 1.0-RC2 in Jira

[Ethan Jewett <es...@gmail.com>]

Hi all,

I must admit that I don't understand the approach here. I meant to
bring this up separately after the release, rather than as a negative
reaction, but I didn't move fast enough :-) In that light, please take
this as an alternative suggestion, based on how I understand the
inter-relation of releases and release candidates (RCs). I'm very very
open to considering other options, but I think we need to have the
discussion about how our release strategy works.

Here's my take:

Frozen JIRA release: 1.0
Release strategy: Frozen in a tag from trunk, then updates are made to
both tag and trunk and release candidates (1.0-RC1, 1.0-RC2) are cut
directly from the tag. If there are release-blocking issues with an
RC, then that ticket should go into the JIRA release that the RC was
cut from (1.0 in this case). Otherwise the issue should go into the
backlog. I realize we haven't been doing this for this release, but
effectively we have because the only activity on trunk have been
updates that are going into the release.

Working JIRA release (next release): 1.1?
Release strategy: We should have a discussion about what open JIRA
tickets should be targeted for this release, then move their "Fix
Release" to this release. If we decide we want to add features that
aren't set up as JIRA tickets, then we should have that discussion and
create tickets for them.

Backlog JIRA release: Backlog (or Unassigned)
Release strategy: All new issues (bugs and feature requests) should go
into this release in JIRA. Issues can be moved from the backlog into a
specific release, but it should be based on some sort of consensus, or
be open to veto. Developers should be encouraged to work on the issues
in the backlog as they are able, but I'd think the core team would
focus mostly on issues assigned to the next release (recognizing, of
course, that this is a classic open source "scratch your own itch"
situation and people will work on whatever they want). If an issue is
fixed while it is in the backlog, then the resolved ticket should be
moved into the current working release (1.1 in this case) so that it
is picked up in the release notes.

Thoughts?

Ethan

On Tue, Feb 23, 2010 at 11:54 PM, Richard Hirsch <hi...@gmail.com> wrote:
> I created a new release in JIRA and started assigning issues to it.
>
> If anyone else has any features or bugs tro fix, then please add this
> info to JIRA
>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310850&fixfor=12314801
>
> D.
>