[sugar] Release process
michael at laptop.org
Wed May 28 02:00:00 EDT 2008
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.
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.
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.
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).
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
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!
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.)
More information about the Sugar