On Thu, Apr 17, 2008 at 12:02 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> 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 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
