Re: [cross-project-issues-dev] Delaying Milestones (was: DSDP-TM request

[Ed Merks <merks@xxxxxxxxxx>]

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