Bernardo Innocenti wrote: > Many centralized projects I've worked for tend to have a 2/3 > development and 1/3 code freeze time share in each release cycle, > which seem like a good compromise for a lightweight development > process that still allows enough time for stabilization.
Despite the use of git, our process as a whole is still centralized because developers don't generally build their own OS images. To test our work in an integrated fashion, we need to drop it in the builds that other people use, running the risk of breaking them. So we need to be extra careful with every little change we make, and this slows us down even further. I've started building my own images a few weeks ago and found that it is not at all difficult. All I had to do was really cloning the pilgrim repo and changing the build name from joyride to xtest. A build generally takes 10 minutes on my desktop PC. My build system is x86_64 and Fedora 8. Anything that would run a mock chroot would probably work. So I can finally be careless most of the time and break whatever I like without consequences except that *my build* will not work *for me*. Distributed projects can afford to have very narrow merge windows (just 2 weeks for the Linux kernel) and long stabilization phases. It's possible because people can keep working on new features during code freeze, and when their work finally gets merged upstream, it is already tested in personal trees and then in topic trees. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
