[7505] in Release_7.7_team
Re: DKMS progress, and how to upload it
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Sat Jun 18 08:23:27 2011
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jonathan Reed <jdreed@MIT.EDU>
In-Reply-To: <alpine.DEB.2.00.1106172301310.16255@tyger.mit.edu>
Date: Sat, 18 Jun 2011 08:23:17 -0400
Cc: release-team@mit.edu, debathena@mit.edu
Message-Id: <3FD2430F-0F64-42E3-9F39-5CF9F901895E@mit.edu>
To: Geoffrey Thomas <geofft@mit.edu>
Content-Transfer-Encoding: 8bit
Thinking about this, I'm really on the fence between all these options. I think I slightly prefer a combination of 3 and 2. Manually upload the packages into -development and let people test. Then test our upload code (manually) against -proposed and leave the packages there for the requisite number of days and make sure the -proposed cluster machines don't fall over. Then move the debathenify code into production and let it upload.
The upload code hasn't substantially changed from the old debathenify code, right?
OTOH, waiting until Oeniric to test automatic upload is not terrible, provided it's documented in Trac, since Oneiric is not going to be a cluster release.
-Jon
On Jun 17, 2011, at 11:13 PM, Geoffrey Thomas wrote:
> 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
