esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Re: Release 1.0-RC2 in Jira
Date Thu, 11 Mar 2010 14:53:41 GMT
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 <hirsch.dick@gmail.com> wrote:
> This is closed
>
> On Thu, Mar 11, 2010 at 3:46 PM, Ethan Jewett <esjewett@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
>> <yojibee@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 <esjewett@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 <esjewett@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.rabellino@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
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >
>> >
>>
>

Mime
View raw message