Universe QA for Hardy

Scott Kitterman ubuntu at kitterman.com
Wed Oct 31 12:52:08 GMT 2007

On Wed, 31 Oct 2007 12:37:28 +0900 "Emmet Hikory" <emmet.hikory at gmail.com> 
>MOTUs, Contributors, and other interested parties,
>    As Hardy will be a Long Term Support release, there are
>significant benefits to aggressively pursuing QA.  I've compiled the
>following list of QA goals: I'd encourage anyone to add to the list,
>or suggest additional measures that can help with the process.
>Hardy should have no Not Built from Source, Failed To Build From
>Source, or Outdated packages:
>    Ideally, Hardy should not include any binary packages for which
>there is no associated source or any source packages that do not build
>on the hardy toolchain.

We also need to look at removing obsolete toolchain bits.  There is a 
reducing redundancy spec for Hardy that was discussed at UDS yesterday.  I 
didn't know everyone there, but siretart and slangesek were the only other 
MOTU that I know of that were their.

The push in that discussion was to get thing out of Main and into Universe. 
 We need to look at pushing old bits out of the archive entirely.  

I got the remaining GCC 2 packages removed yesterday.  For Hardy it looks 
like all of GCC	3 and possibly (IIRC) GCC 4.1 will be in Universe.  It 
would be good to look at packages still built against the earlier GCC 
versions in Universe to see if they can be rebuilt or are perhaps 
sufficently crusty that they should be removed.

Python 2.4 will almost certainly be in Main for Hardy.  I think that with a 
few exceptions (Zope being the elephant in the tent) we should try to have 
Python applications and modules all working with Python 2.5.  

>    There is a manual tool that generates a list of NBS packages (1).
>These packages will be removed from the archive as soon as there are
>no reverse dependencies: please review the rdepends, and adjust them
>to work with more current packages.
>    Launchpad tracks all build failures (2) , but this list is not
>reduced when packages later succeed.  Any volunteer to work with the
>launchpad team to extract a current list of FTBFS packages would find
>their effort well received.
>    Currently, outdated tracking is only done for main (3).  The
>scripts off which this is based are available (4): if anyone wants to
>run them against universe periodically, and make the results
>available, this would be helpful.
>Packages should install and purge cleanly:
>    Every package shipped should minimally support installation,
>removal, and purging.  Having it run and do something is nice and all,
>but without this level of functionality, users have difficulty
>investigating the software available in the archive.
>    The Ubuntu QA debcheck system (5)  currently runs every 6 hours,
>and provides detailed information on packages whose relationships
>cannot be satisfied, either at all or based on policy (e.g. universe
>may not depend on multiverse).  Any package shown here should be
>updated to not appear.
>    The ftp-master scripts (4) also contain a problems checker.  The
>output for main is available (6), but again, there is no output for
>universe.  I'm not certain this provides any useful information not
>already presented in debcheck, but if anyone wants to run it against
>universe regularly and post the results, it may be useful.
>    To catch problems that are not solely a result of package
>relationships, it would be additionally nice to schedule piuparts (7)
>runs during the development cycle.  If resources are available, I
>would think that runs at DebianImportFreeze, FeatureFreeze, and
>BetaFreeze would be ideal.  When run during the feisty cycle, it took
>about a week to process the entire archive, so a similar duration
>should be expected for Hardy runs.
>Integration of Debian improvements:
>    Debian does lots of great work, which isn't always well matched to
>our release schedule.  This work often includes fixes for all sorts of
>annoying bugs: we should do our best to integrate the results of this
>effort into Ubuntu.
>    Firstly, Debian has a concept of "Release Critical" bugs: whenever
>possible, we should not ship any package that contains a "Release
>Critical" bug when there is a known solution.  Please review the RC
>Bugs list (8) periodically, and sync / merge / backport as
>appropriate.  This page should contain no entries on release day.  For
>those interested in further cleanliness, people are welcome to review
>the full list of open Debian "Release Critical" bugs (9), and provide
>    Secondly, Debian provides lots of regular maintenance to packages.
> When a package has no Ubuntu modifications, we should request
>synchronisation after DIF with the following guidelines:
>1)  If it is past Beta Freeze: only sync if RC bugs are fixed
>2)  If it is past Feature Freeze: only sync for identical upstream version

If pitti's new freeze structure is approved (I think it likely it will) 
then this will need to be modified to allow upstream bugfix only updates.  
We'll have to decide on how we wan't to manage that in MOTU.

>3)  If there are reverse dependencies: test the transition plan prior to 
>    In past releases, we have used multidistrotools (10) for this.
>The last URL I had appears to be down: would anyone be willing to host
>    Thirdly, as with Gutsy, MoM (11) should be kept running through
>the end of the cycle.  While the vast majority of packages won't be
>merged after DIF, it may reduce the effort required to integrate
>Debian changes for modified packages.
>Integration of community contributions:
>    Lots of people use launchpad, and submit patches.  Some are better
>than others.  All bugs with attached patches (12) or tagged "patch"
>(13) should be reviewed, and the patches either accepted, modified, or
>Packages should be useful:
>    Sometimes packages become no longer useful (e.g. drivers for a 2.0
>kernel, plugins for KDE 2, PHP3 extensions, etc.).  In some cases,

Note that PHP4 is also gone, but there is still some cleanup work for that. 
 I expect there are still packages that recommed/suggest apache (vice 
apache2) also.

>there is a successor project, or there was a transition.  We should
>identify these packages, and try to clean up.  This is another way in
>which multidistrotools(10) can be useful, to catch Debian removals,
>but independent investigation is also useful.  If requesting the
>removal of a package, please consider:
>1)  Removal of the package should not break any other packages
>2)  There should be a replacement that provides the functionality
>3)  There should be a transition plan for users
>    In some cases this means the upload of dummy packages to point to
>the replacements.  In some cases this means adjustment of dependencies
>/ recommendations / suggestions to indicate the correct package.  In
>some cases, no action is required.
>Packages should be based on the Hardy toolchain:
>    It would be nice if everything shipped in Hardy was built with the
>hardy buildchain.  This ensures that:
>1) Everything can be built from the hardy buildchain
>2) Any improvements to the toolchain or package tools are passed to the 
>3) -dbgsym .ddebs are generated for all the packages
>    Ideally, we could run some script starting around FeatureFreeze to
>find any packages not build for Hardy, and queue builds for these
>packages.  Collecting this list either requires scanning the
>hardy-changes mailing list archives or integration with launchpad,
>compared against Sources.gz.  Anyone who wants to write this script
>may do well to coordinate with the person tracking FTBFS data if
>integration with launchpad is preferred.
>There should be as little as possible in the oldlibs section:
>    The oldlibs section of the archive contains only deprecated
>libraries.  In addition to the other relationship tracking, debcheck
>(5) provides a list of packages that need porting.  In many cases this
>is a simple adjustment of build dependencies and a recompile, although
>more significant porting work is sometimes required.  Please review
>this list, and try to reduce as much as possible.
>Packages should be linda and lintian clean:
>    For extra points, everything in the archive should be linda &
>lintian clean.  This is an immense effort, and actual implementation
>would likely generate a huge variation against Debian.  A smaller
>target is to check packages with Ubuntu variations, and ensure lintian
>/ linda cleanliness of those packages: the remainder should be
>deferred until everything listed above is complete.

I'd suggest that for packages where we have no diff from Debian, we should 
send patches and work with Debian Maintainers to get them fixed in Debian 
early in the cycle so both distros benefit and the Debian/Ubuntu diff is 
keptt minimized (now is also a good time to be feeding relevant patches 
back to Debian so there is less merging to do at the end).

>Call for volunteers:
>    Completing this effort will require large amounts of effort, time,
>bandwidth, and processing.  Specific immediate tasks to be claimed
>A: Coordination with the launchpad team to collect list of packages
>for which the latest uploaded version FTBFS, presentation, hosting,
>and maintenance of this list.
>B: Porting / Running ftp-master scripts against universe packages, and
>hosting the results
>C: Volunteering to run piuparts for any of the three freezes (three
>different people would be nice, unless someone is incredibly
>motivated), and hosting the results
>D: Hosting MDT against Debian Unstable for the Hardy cycle
>E: Maintaining a list of not-built-for-Hardy packages
>    Please reply to this list if you are working towards any of the
>goals above, to make sure we don't duplicate too much effort.  Extra
>points for parsing the results, presenting a nice web interface, and
>allowing easy claims by developers (comments).


Thanks for this.  It's a good (and daunting) list.

One other point to look for is packages that duplicate libraries and other 
programs that we have in the archive internally.  Ideally we'd ship one and 
only one copy of all the code we ship.

Scott K

More information about the Ubuntu-motu mailing list