Release process

[Michael Stone]

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.)