incubator-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 14:49:09 GMT
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