[7506] in Release_7.7_team
Re: DKMS progress, and how to upload it
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Sat Jun 18 14:55:01 2011
Date: Sat, 18 Jun 2011 14:54:53 -0400 (EDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
cc: release-team@mit.edu, debathena@mit.edu
In-Reply-To: <3FD2430F-0F64-42E3-9F39-5CF9F901895E@mit.edu>
Message-ID: <alpine.DEB.2.00.1106181447510.8439@tyger.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
The upload code has not changed at ~all (modulo a tiny fix, r25141,
which only became relevant as part of this work) the only change is
putting two conditionals into the code that creates the
openafs-modules-generic etc. metapackages.
I'm fine with your proposed resolution and I'll manually upload to
development tonight if nobody has other opinions. That reduces the window
that we need to be worrying about kernel updates and manually pushing
modules packages to production. (I used to have an option 4 involving
pointing the production checkout at -development, but I believe the
debathenificator only is aware of production and -proposed and not
-development, so that would also have required new code. But pointing the
production checkout at -proposed also works around this, and has been
tested because it's only relatively recently that the debathenificator
has been uploading directly into production.)
--
Geoffrey Thomas
geofft@mit.edu
On Sat, 18 Jun 2011, Jonathan Reed wrote:
> 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
>
>
