New Planning Thoughts draft.

[Tomeu Vizoso]

On Thu, Apr 17, 2008 at 12:02 PM, Marco Pesenti Gritti
<mpgritti at gmail.com> wrote:
>  * Smaller-and-faster (focused) releases are an interesting idea but I
>  think they are also quite a challenge. We need to ensure that we are
>  able to parallelize the various streams. For example, if we do a
>  release which focuses on networking, someone will keep working on UI
>  and performance at the same time. How do we avoid clashes? Having
>  multiple streams going on concurrently certainly complicate the
>  development process. I don't have previous experience of this kind of
>  development. We can try to go through it and try to anticipate how it
>  would work in practice. Or even better maybe someone have experience
>  that can be shared here.

I see this too as a hard problem and don't really have experience
neither. What I would expect is that working on frequent time-based
releases with features slipping as needed works best for projects like
linux distros, where slipping a feature grossly means not updating a
set of packages to the latest stable version.

That works because those packages generally depend on other parts of
the system in a quite controlled way, through well-known and very
stable APIs.

In our case, the sugar codebase is much smaller, and those few
components are more tightly coupled and the APIs are still immature.
The codebase being small means that the possibility of a conflict when
merging features is much bigger.

All this overhead with merging and unmerging features means lots of
work for the small development team. Also means much more work for the
QA team, that cannot test each feature separately and expect the final
product with the final features in it to work as expected without
retesting everything.

I'm not advocating for omnibus releases, just a general comment.

Thanks,

Tomeu