Emmet Hikory wrote: > 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. > > 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 > fixes. > > 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 > 3) If there are reverse dependencies: test the transition plan prior to > syncing > > 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 > this? > > 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 > rejected. > > 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, > 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 > packages > 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. > > Call for volunteers: > > Completing this effort will require large amounts of effort, time, > bandwidth, and processing. Specific immediate tasks to be claimed > are: > > 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). > > 1: http://people.ubuntu.com/~ubuntu-archive/NBS/ > 2: https://launchpad.net/ubuntu/hardy/+builds?build_text=&build_state=failed > 3: http://people.ubuntu.com/~ubuntu-archive/testing/hardy_outdate.txt > 4: http://ftp-master.debian.org/testing/update_out_code/ > 5: http://alt.qeuni.net/~william/debcheck (Thank you William Grant) > 6: http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html > 7: http://packages.ubuntu.com/hardy/devel/piuparts > 8: http://django.ajmitch.net.nz/rcbugs/ (Thank you Andrew Mitchell) > 9: http://bugs.debian.org/release-critical/debian/all.html > 10: https://wiki.ubuntu.com/MultiDistroTools > 11: http://merges.ubuntu.com/universe/html > 12: http://tinyurl.com/39w2p3 > 13: https://launchpad.net/ubuntu/+bugs?field.tag=patch > > Emmet,
I'm in, let me know where my dumb ass can help out. I usually try to make sure everything in the archive builds so I will try to jump in to that and the binaries with no source stuff.. Thanks, great e-mail and goals!! Barry deFreese (aka bddebian) -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
