Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cross-project-issues-dev] DSDP-TM requests delaying our M6 dropby 4 days

Hi Dave,
 
I disagree because I think it all depends on the consumers.
 
As far as I know, we don't currently have any consumers who require
strict train date. But we do have consumers who much rather download
a Milestone for their personal use and adoption, rather than an I-build
or an M6 and later M6b ... that's all extra work for lots of people (me
as release engineer as well as adopters, testers and downloaders)
which I'd like to avoid if I can.
 
If it turns out that there is ANY consumer who DEPENDS on the
train schedule, I'll stick with the schedule because that's what we
committed and what everyone needs to be dependable on.
 
But as long as nobody depends on it, I'd rather make life easier
for my other consumers, placing a clear message: THIS is the
download you should use as "milestone 6" because it fulfills
the promises we have given (availability date, API, quality) to
the greatest possible extent.
 
Makes sense?
 
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 


From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Freitag, 04. April 2008 18:03
To: Cross project issues
Subject: Re: [cross-project-issues-dev] DSDP-TM requests delaying our M6 dropby 4 days


Martin,

Lack of testing is no excuse for slipping dates ... as you can see from other typical eclipse project's behavior :)

My advise is to stick with the train metaphor ... if you leave the station late, you never know what other train you might run into later on, down the tracks.

While it does greatly depend on the wishes of your adopters and committers, I recommend you declare M6 with whatever you have, with whatever amount of testing you can do, but (as you've done here) warn people it hasn't gotten as much testing as you would have liked, due to the important API work, so if anyone runs into a blocking or critical issue, you would consider providing them with an M6b upon request.

Besides ... once one project slips, it'll change our mindset and you know who else will start asking for a slip too. :)

I think there can be good reasons to slip a schedule, but not so much for "unknown, potential problems" ... only for "we have a known problem that will prevent adoption of the milestone".

Make sense?

Thanks,

Back to the top