[tahoe-dev] the "release buildbot" plan

[Brian Warner]

We spent some time around the office today talking about how to set up a
"release buildbot", which would be responsible for building debian packages
for Tahoe releases, and would help us develop "point releases" quickly.

The goals are:

 allow allmydata.com to point production machines at an APT repository that
 will only contain Tahoe releases: not intermediate/nightly builds. The ops
 staff should be able to do an apt-get upgrade at any time and be confident
 that they won't be installing non-released code.

 We should be able to create "point releases" easily. If we've released 1.1,
 and two months later trunk contains a number of unstable changes (such as
 the Accounting stuff that zooko and I are working on), and we discover a
 severe bug in 1.1 that needs an immediate fix (which can't wait for 1.2),
 then we'll need to be able to create 1.1.1 .

Here's my writeup of the plan we came up with.

   We'll change the existing trunk buildbot to ignore tags, and to build
   debian packages with "r1234" version identifiers (rather than the current
   "1.1-r1234").

   Then we'll create a new "release buildbot", which:
    follows a separate "release darcs repo"
    understands tags:
     the Change that represents a tag will have a .revision attribute, non-tag
      Changes will have .revision=None
     the Darcs checkout step needs to "darcs get --tag REVISION"
    only builds+uploads debian packages for tagged builds, never for intermediate
    pushes debs to a separate "release APT repository"

   The prodnet servers will pull from the release APT repository.

   When we make a major release and decide to give up the easy ability to
   create point releases off the previous major release, we will push all
   patches (including the new major-release tag) from the trunk-repo into the
   release-repo, triggering the creation of debs, which will be available for
   prodnet.

   When/if we need to make a point release, we push patches to the
   release-repo until the problem is fixed, then we tag and push. This will
   trigger new (point-release) debs, which will appear in the APT repo where
   they can be installed on prodnet. Then (ideally) we push everything from
   the release-repo into the trunk-repo (handling any merge conflicts as
   necessary). This will insure that the point-release fixes are also present
   in trunk. The point-release tag that winds up in trunk won't affect any
   builds. Any numbered+tagged release can be retrieved from the trunk repo.

  Remaining issues:
   the only way to get numbered release debs is from the release buildbot,
   and hence by pushing the changes+tag into the release-repo. This means
   that the moment we release 1.2.0, we lose the ability to make point
   releases from 1.1 (like 1.1.1). Likewise when we release 1.2.1, we lose
   the ability to make 1.2.0.1 . (At least, a 1.2.0.1 wouldn't get
   buildbot-generated intermediate builds.. if you fetch a 1.2.0 tree, make
   some changes, tag it with 1.2.0.1, then push the result to the
   release-repo, the buildbot will create 1.2.0.1 debs, which is probably
   enough).


cheers,
 -Brian