Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cross-project-issues-dev] Delaying Milestones
Hi Bjorn,
 
it looks like we're all on the same page now - good!
 
It was clear to me that we wouldn't ever deliberately let Ganymede slip.
That's why I chose Fri Apr 11 as our drop dead date -- knowing that
we're not yet in any EPP package so it should be fine for everybody.
 
Let me also mention that I didn't want to accuse or talk bad of anybody.
I just wanted to hightlight that slipping dates _can_ happen, for whatever
reason.
 
And, just to mention, we *do* depend on the CDT with our RemoteCDT
integration, and that very fact along with having to adopt P2 cost me
 
But basically, the CDT team did exactly what I did: given theat they
could start integration testing late due to Platform delay, they informed
the Cross-Project group about delaying their milestone. I didn't object
since I thought we could handle it. Well, and now I've informed the
group about a similar situation.
 
Again - I think it's good we're discussing this to ensure that everyone
is on the same page. What I get from the discussion is that Projects
are free to do what they like, as long as Ganymede itself is not delayed.
 
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
 
 

Second Issue: I believe the Ganymede milestone process is flexible as long as we reach closure by the final milestone date. Thus if the Platform team produces an M6 a few days late, that's fine as long as the downstream projects can recover - of course it is up to the Platform team to communicate with those downstream projects and make sure that everything is going to work. (Perhaps you're saying that didn't happen?)  Similarly, if the CDT team produces an M6 at the last minute, that's fine because nobody depends on CDT - it will mean that CDT's M6 will be less well tested than other M6s, but that's the CDT team's choice.

Thus the DSDP-TM team is welcome to produce its Ganymede M6 bits later than the official +N date as long as that doesn't cause the whole Ganymede M6 to slip.

Third Issue: The final Ganymede builds have not been on time because *I*, Bjorn, did not get the Ganymatic working correctly in time. I did not ask permission for this because I did not plan to fail on this - instead I just worked away at the bugs until I got it working and thus the final build complete. At the same time, I consider this a less important problem because we're doing a coordinated release, i.e., we're coordinating the releases of all the projects - the projects all got their bits done on time, so the major goal of each Ganymede milestone was met.

Oberhuber, Martin wrote: 
(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.
Ah, so you're saying that the dates *do* matter to your consumers? Your previous email said that the dates don't matter which I read as saying that the consumers would be happy to wait until M7. If the dates do matter, then we need to think of some other solution.
(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.
Do your consumers download your DSDP-TM distro or do they download the Ganymede distro? If the former, then I don't see the problem: just tell the consumers to download your DSDP-TM M6 (what you're calling M6a) on date X.
(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.
As long as an M6 in (some) days doesn't cause the Ganymede M6 to slip, I don't see any problem with this at all. So the key question is "will you be able to release DSDP-TM M6 in time to prevent Ganymede M6 from slipping", i.e., before April 10th? If you're going to delay until April 11th, please coordinate with Markus about whether he is going to have time to build the EPP packages.
But note that we asked known consumers of ours on the
Mailing list, and everybody agreed that (d) is what
They like.
Great. But your consumers are not the only Ganymede consumers and therein lies the problem. Again, the DSDP-TM team is welcome to have as many additional milestones as it needs to satisfy its consumers: participation in the simultaneous release does not constrain a project from doing the right thing by its adopters and users.

- Bjorn
--

[end of message]

Back to the top