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
Martin,
There are a couple issues here. (Not everyone agrees with me on these issues.)

First Issue: I believe the annual simultaneous releases are exactly that: simultaneous releases by multiple projects. For example, the project teams have made it clear that they do not want to invest the effort to make an annual integrated release but rather they want to remain with a coordinated release. By having a coordinated/simultaneous release, the obligation on the projects is to provide a set of bits for each coordinated milestone. It's a one-way obligation in that it does not constrain the project from having more frequent milestones or releases, nor does it prevent the project from providing the same exact bits for subsequent coordinated milestones.

Thus the DSDP-TM team is welcome to produce one set of bits for Ganymede M6 and another set of bits for DSDP-TM M6 a week later - or whatever the project wants.

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