[6254] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: Outstanding issues for Debathena/Athena 10 merger

daemon@ATHENA.MIT.EDU (Jonathan Reed)
Mon Mar 2 12:44:21 2009

Cc: athena10@mit.edu, release-team@mit.edu
Message-Id: <5ED4D975-0C5C-4F47-8BEF-8EB4EA98ED13@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: Tim Abbott <tabbott@mit.edu>
In-Reply-To: <alpine.DEB.2.00.0903021145540.13082@vinegar-pot.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Mon, 2 Mar 2009 12:43:23 -0500
X-Spam-Flag: NO
X-Spam-Score: 0.00

Before Wednesday, I'd love to remove the HTML content on  
athena10.mit.edu and replace it with a page that says "Athena 10 is  
now Debathena Beta" or some such and redirect to http://debathena.mit.edu/beta/ 
.

It sounds like the Debathena repository is the more up to date one,  
with the exception of debathena-thirdparty and friends, which should  
be easy to build since they're just metapackages.

What problems, if any, do people see with this proposal to change the  
HTML content on athena10.mit.edu?

Note that if we do this, I'd like to _not_ merge debathena/beta into  
the main site right away.

-Jon


On Mar 2, 2009, at 12:34 PM, Tim Abbott wrote:

> OK, I've repurposed the script that generates the data for
> http://debathena.mit.edu/package-list to diff the version numbers in  
> our
> two repositories and gone through the output.  If people go through  
> and
> fix differences that we don't want (e.g. uploading to Athena 10 the  
> work
> over the weekend), I can run it again and recompare later tonight.
>
> Differences are as follows.  I use shorthand below fairly extensively;
> "We" and "You" refere to the Debathena and Athena 10 repositories.   
> When I
> mention "we have debathena-foo-config 1.0", that in general means  
> that the
> other repository has an older version.  When I say "Seems OK", I  
> generally
> mean that the condition is unproblematic for switching over to only  
> using
> debathena.mit.edu.  If I don't say "Seems OK", it means I think  
> something
> should maybe be done.
>
> Differences because of work over the weekend:
>
> - We have the new debathena-shell-config 1.10 (the ATHENA_USER thing
> geofft committed Friday).
>
> - We have the new debathena-gdm-config 1.10 (merging in the -athena10
> "branch")
>
> - We have the new debathena-archive-keyring
>
> - We have the new debathena-standard 0.2.5 (depending on -archive- 
> keyring)
>
> - We have the new debathena-machtype 10.0.0-0debathena4 (improving
> machtype -L)
>
> - We have the new debathena-athinfod 10.0.0-0debathena2 (using the new
> machtype and other cleanup)
>
> - debathena-chrony-config and debathena-ntp-config versions mismatch,
> because of broder's commit to use TRANSFORM_FILES Saturday.   
> Differences
> are further complicated by the fact that his code doesn't build on  
> dapper
> (so that we have an older version on some releases and a newer  
> version on
> others).  Probably not a big deal.
>
> Other interesting differences:
>
> - We don't have debathena-thirdparty at all.  Can someone deal with
> building and uploading all of these to Debathena repository?
>
> - We have newer debathena-athdir 10.0.0-0debathena1; I think here  
> Athena
> 10 is a month out of date?
>
> - our debathena-build-depends packages differ, apparently because  
> broder
> uploaded a version bump to 1.3 without committing it a long time ago.
> I've committed a new 1.4 to deal with this.
>
> - We don't have a copy of debathena-libreadline-dev.  I don't recall  
> the
> story of this, but it apparently had something to do with discuss?
>
> - We have a slightly different set of openafs modules for old kernels.
> Seems OK.
>
> - You don't have -manual-config on releases other than sarge, edgy,  
> and
> feisty (i.e. the now unsupported ones).  Our packages are probably  
> also
> out of date.  Seems OK.
>
> - Our pine packages differ.  Since we now use alpine, this doesn't  
> really
> matter.  Seems OK.
>
> - You have copies of debathena-linerva and debathena-linerva-pam- 
> config.
> I think we don't have them because they're unlikely to be of general  
> use.
> Seems OK.
>
> - We have a barnowl package.  Seems OK.
>
> - We have a debathena-alpine-config package on dapper, etch, and gutsy
> (where it probably doesn't work without getting alpine from  
> backports).
> Seems OK.
>
> Differences in things that no longer exist in SVN and thus don't  
> matter:
>
> - You have a debathena-afuse-automounter package, which no longer  
> exists.
> Seems OK.
>
> - We both have random versions of debathena-cluster-software, which no
> longer exists.  Seems OK.
>
> - You have a copy of debathena-config-build-common, which no longer
> exists.  Seems OK.
>
> - You have the debathena-wmaker package, which no longer exists.   
> Seems
> OK.
>
> - We have libfile-temp-perl on more releases than just feisty.   
> Seems OK.
>
> - You have debathena-libpam-xauthority, which no longer exists.   
> Seems OK.
>
> - You have a "rectest" package for testing.  Seems OK.
>
> - We removed more patched Kerberos packages from our repository.   
> Seems
> OK.
>
> 	-Tim Abbott


home help back first fref pref prev next nref lref last post