I have to respectfully disagree with much of Mark's vision. I do agree that short predictable
release cycles are good. Release cycles should be short enough that if something misses a
release window waiting until the next window is not a major problem. Allowing code to be
released when it is ready and not generating pressure to release something before it is ready.
Arguments that say we should do X now because another project is going to use the release we
are preparing are completely inappropriate. If code can not stand on it's own merits it
should not stand.
Much of what Mark has described is process oriented and ignores the developer who makes code
changes only because they have an itch. If you don't make room for itch scratching developers
you loose much of the vibrancy and vitality you otherwise would have had.
I find the idea of multiple distributions coordinating intentionally on a single release of a
product with the knowledge of the community of that product suspicions. This seems to say to
the software development projects out there: We are the gate between you and users tremble
However I slice it I can not see a project caring when a meta project will use them as a good
thing. It just feels like an excuse to be slopping either because you don't expect your
software to get used or because of extra pressure to include changes because your software
will get used.
Meta projects that have frequent regular releases of what ever is ready when they are building
a release do seem to be a good thing, as that removes the pressure from caring from other
projects. You know if you release something even if it doesn't get used now it will get used
soon enough that it doesn't matter.