esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: Release 1.0-RC2 in Jira
Date Thu, 11 Mar 2010 15:00:29 GMT
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 <esjewett@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message