[7504] in Release_7.7_team
DKMS progress, and how to upload it
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Fri Jun 17 23:13:26 2011
Date: Fri, 17 Jun 2011 23:13:17 -0400 (EDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: release-team@mit.edu
cc: debathena@mit.edu
Message-ID: <alpine.DEB.2.00.1106172301310.16255@tyger.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Liz and I tested the DKMS transition packages (Trac: #243) on all current
Ubuntu releases (out of http://debathena.mit.edu/apt-dkms, which we
created for this purpose) and it works fine.
Unfortunately I just realized that, since this is part of the
autodebathenficator and we've so far been letting that upload packages
straight to production, we don't really have a good mechanism for running
one version of the autodebathenificator code uploading into production and
a newer one uploading into -development. I can see a couple of options:
1) Put something together to allow us to do so. (I think the simple
solution of running debathenify-openafs twice will in fact work).
2) Manually upload the built transition packages into -development, let
them follow workflow policy into -proposed and -production with "damove"
as usual, but when we move them into production, also svn up the
production checkout of debathenify-openafs.
3) Test this code in some other manner and override workflow policy and
just "svn up" the production checkout of debathenify-openafs in a few
days. We've done testing on VMs running debathena-workstation; we can also
run around some clusters and test that way.
The primary disadvantage of 2 is that we won't have ever run the upload
code against the production repository until Oneiric (but all of the code
has been tested against the for-the-nonce apt-dkms repository, so I don't
really expect this to be a problem). That would be why I'd prefer 3, but I
don't have strong opinions favoring one of these answers. 1 is probably
the theoretically cleanest, but it seems poor to introduce new
code/mechanisms as part of testing other new code.
--
Geoffrey Thomas
geofft@mit.edu
