[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cross-project-issues-dev] Delaying Milestones
|
Hi Ed,
> Does it make sense that you might drop another version of
> DSDP a bit later and that doing so wouldn't break anyone
> downstream?
Well that's what I was talking about. It does make sense IMHO.
I'm not aware of any downstream consumers in Ganymede, and
DSDP-TM is not part of any EPP Package yet (though it looks
like we'll go into the JEE package soon).
That's why I'd like to grab the bull by the horns and get
our APIs clean, even if it takes few extra days.
For me, the time limit is this Friday which happens to
be EPP Train Day. But if anybody is concerned, I could
certainly also do the same as CDT did and release on
Wednesday - though I'd personally prefer getting two
extra days for desting.
Note that I never talked about adding features, but
merely about fixing the API that's broken. And testing
the fixes properly, such that nobody is broken
downstream.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx
> [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Ed Merks
> Sent: Montag, 07. April 2008 19:58
> To: Cross project issues
> Cc: Cross project issues; cross-project-issues-dev-bounces@xxxxxxxxxxx
> Subject: Re: [cross-project-issues-dev] Delaying Milestones
> (was:DSDP-TM requests delaying our M6 drop by 4 days)
>
> Martin,
>
> I don't know all the specifics, but if things are literally
> broken then
> delivering broken goods just doesn't cut it; I think p2 was
> of that ilk.
> Also, if the builds are broken, well, the train was off the
> tracks, what
> can you do but keep trying until it's back on. But if you
> want to delay so
> you can add new function, that seems not a good precedent.
> In general,
> providing what you have and let the train continue on
> schedule seems best.
> Of course I personally have no issue with you dropping an I
> build into the
> M6 Ganymede and instead calling some subsequent build M6 for your
> component. And if the build ends up being held up for other
> reasons and
> you can drop an M6 version in a little later without breaking
> the train,
> that seems okay too. Obviously my opinions are just my
> own... I certainly
> don't want you to feel that you're being held to a higher
> standard than
> others or are being put in a more restrictive position. It's
> best if we
> all just try to be flexible. Does it make sense that you might drop
> another version of DSDP a bit later and that doing so
> wouldn't break anyone
> downstream?
>
>
> Ed Merks/Toronto/IBM@IBMCA
> mailto: merks@xxxxxxxxxx
> 905-413-3265 (t/l 313)
>
>
>
>
>
>
> "Oberhuber,
>
> Martin"
>
> <Martin.Oberhuber
> To
> @windriver.com> "Cross project issues"
>
> Sent by:
> <cross-project-issues-dev@eclipse.o
> cross-project-iss rg>
>
> ues-dev-bounces@e
> cc
> clipse.org
>
>
> Subject
>
> [cross-project-issues-dev] Delaying
> 04/07/2008 01:30 Milestones (was:
> DSDP-TM
> PM requests delaying our
> M6 drop by
> 4 days)
>
>
>
> Please respond to
>
> Cross project
>
> issues
>
> <cross-project-is
>
> sues-dev@eclipse.
>
> org>
>
>
>
>
>
>
>
>
>
> Hi Bjorn, Ed, Dave (and whoever's interested),
>
> I'm glad that we're discussing the issue of milestone delay
> here, since the way we view the train schedule certainly
> is an important aspect of our collective release culture
> (and probably even brand identity).
>
> Note that with Ganymede M6, Eclipse Platform delayed by
> 3 days (Mar.28 -> Mar.31); CDT delayed by 2 days (Mar.31
> -> Apr 1); and nobody objected so far. In earlier
> Ganymede milestones, contributing projets were all on
> Schedule, but the final coordinated Ganymede build was
> Delayed (well, I don't actually know how long).
>
> So why did nobody object on those occurrences? I don't
> Want to put the blame on anybody, so I assume that either
> Nobody asked whether it were ok to delay, or the delay
> Were shorter, or just nobody took the time sending any
> E-Mail.
>
> My personal opinion is, that meeting the train schedule
> is super important. Letting deadlines slip may jeopardize
> The entire train. But still, experience also shows me
> That the severity of letting it slip may vary.
>
> So, what are _my_ current options for DSDP-TM?
>
> (a) release M6 today but with API leaks that we know.
> --> M6 is API freeze so we'll have flaky API
> for our entire 3.x branch which can be multiple
> years and block future fixes. Consumers not happy.
>
> (b) release M6 today and continue changing APIs in M7.
> --> Consumers will expect frozen API and still have
> to adopt to future API changes - not nice since
> consumer's plans expect to be able and adopt
> M6 API.
>
> (c) release M6 today and M6a shortly after.
> --> Consumers will happily download and try M6,
> just to learn few days later that they'll
> need to "re-adopt" M6a. Not very nice.
>
> (d) release I20080407 today and M6 shortly after.
> --> Consumers will wait (some) more days until
> M6 is available in stable quality and with
> good APIs.
>
> In my optionion, (d) is the best option and we discuss
> How many "(some)" days are an acceptable delay. If
> anybody - preferredly a real existing consumer of
> our stuff - can argue that (a) (b) (c) is better,
> I can release today.
>
> But note that we asked known consumers of ours on the
> Mailing list, and everybody agreed that (d) is what
> They like. So I'm not happy choosing (a)(b)(c) without
> Good arguments.
>
> Note that I'm not advocating anybody to deliberately
> let any deadlines slip. We've ever sicne joining Europa
> Or Ganymede met each and every schedule. But given
> The current status of finding some API flaws late
> in the game, we think it's in the best interest of
> Our consumers to slightly delay the schedule. If,
> However, you folks think that Ecilpse Collective
> Reputation is more important than our real existing
> Consumers - well please argue for that.
>
> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
