Folks, Here's what I took away from the comments I received concerning my transcript of my conversation with Marco and a few thoughts in response. You should check my summary to see if I misunderstood you.
Regards, Michael Summary ------- Dennis: To date, to our detriment, we have done development and stable releases from the same tree. We should be more like Fedora. Fedora does development in rawhide. Periodically, it forks 'stable' and 'updates' branch-pairs off of rawhide. Yum is handy for testing updates and new changes. Scott: Stable builds are good, but development is necessary. Development requires distributing some incomplete/busted code. Use topic branches freely, but merge code when necessary to get broad testing. It sounds like F9 is ready for broader development. Debian's three-stage change filtration process has worked well for them. Debian's release management involves combing the bug database for regressions and minor bugs found in testing which were discovered after the 14-day grace period from unstable and which haven't already been fixed, documenting known 'wont-fix' and 'relnote' issues, and testing upgrades and installation. Kim: I support change filtration and associate teams with branches: Support with "stable", QA/Test with "testing", and Dev. with "unstable" & topics. The release manager chooses things to move from dev. into testing. However, they need agreed-on 'readiness criteria'. Also, we should identify must-have changes up front. Tomeu, replying to Kim: Whose job would be to make sure that people are working on things that have the highest probability of getting into the next release? The project manager? If so, I guess we can expect some tensions between the release and the project manager. If it's the same person (or set of persons), we could face another update.1. Morgan, replying to Tomeu: I see the project/product manager as the person fighting to get a certain feature set into the release, and the release manager being the one who tries to keep unnecessary changes out of the release (for stability reasons, or to meet the deadline). Claims ------ I. There is no excuse for breaking centralized build streams that others depend on when one-off 'topic builds' and dedicated build streams are available. Please shout loudly whenever you could use a topic build or build stream. They're very easy to make and if large demand exists, it's straightforward to build better tool support. II. Dennis is right that we should maintain separate 'base' and 'updates' branches for each release. However, unlike Fedora, it is only sometimes helpful for us to fork a release off of a development branch. Other times we wish to make an incremental release. III. It's better for people to manually maintain build-streams (and forks of other people's build streams) because it promotes the maintenance of knowledge of bug status and priority in the maintainers' heads. If the maintainers communicate primarily through archived media, then everyone wins because we have both the archived records _and_ fresh, reliable human knowledge with which to make decisions. IV. If we get bigger, then this will cease to scale and we would be well advised to adapt something like the Debian automated filtration process. However, at our present scale, I think I can get us better results by personally negotiating each block of changes. Consequently, with Dennis' help, I'm maintaining build streams for the 8.1.1 release (this week) and soon, for the 8.2 (August) release. If you've made or intend to make changes since 703 and haven't yet done so, you need to come talk to me about how to we're going to release them! Other Thoughts -------------- V. Freeform change filtration seems to rely on large quantities of independent changes and on larger quantities of test effort for filtering those changes. At the moment, we seem to have neither large quantities of change nor large quantities of available test effort. VI. We receive a fair amount of software which we don't wish to include in our releases but which we still want to make available for easy installation by end users. Package management is a good way to provide this software. Consequently, our package branches should contain more software than we put into our builds. VII. There are several important members of our community who refuse to have anything to do with the Fedora community and the Fedora packaging process. Justified or not, these members' adamant boycott of the Fedora processes and community appears to me to foreclose the possibility of a purely Fedora-based workflow. This substantially increases the cost of any arrangement we might make because it leaves OLPC responsible for maintaining server infrastructure which could profitably be left to Fedora. (It also, dramatically increases the time that both Dennis and I have to spend manipulating your patches/packages. Do us both a favor - do things the Fedora Way.) _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar