Debian QA meeting schedule preparation

Please add tasks below. For each task, say clearly if it is just a talk+discussion (BOF), an open discussion about any aspect of QA that you want to discuss in order to improve it, or if it's likely to lead to work by several participants during the meeting. This way, we know if it has to be scheduled early or not.

If you want to help with a given task, add yourself to the list.

[talk] Improving processes for archive rebuilds and piuparts tests

Lucas will describe how we work inside collab-qa. The objectives are:

Participants:

[work] Displaying LowThresholdNMU info on the PTS

It would be great to have a logo for NMU-friendly and non-NMU friendly packages on the PTS. This would allow to easily identify in which category a package is. Additionally, we should generate some stats on the number of packages in each category, to follow how this evolves.

Needed: PTS hacker for the PTS part.

Participants:

[talk+work] Removal/orphaning of useless/unmaintained packages

Lucas will demo the scripts he wrote to start working on that. Objectives:

Participants:

[bof+work] workflow for orphaned packages

We have a lot of orphaned packages in the archive. We should try to find maintainers for those that are worth it, and have a process to remove the other packages. A workflow similar to the one used for finding useless/unmaintained packages could probably be used.

Participants:

[bof+work] automatic buildd problem detection

Often the testing transition of packages get stuck because a builds fail, just because the chroot is broken, packages are temporarily uninstallable or something like that. Currently, a lot of time is needed to detect those and fix them up. Could we automate this? How can we work around this? [This could be extended into a more general "what to do with our buildds" session, but the buildd admins are usually not really open for help]

Participants:

[bof+work] Personal Package Archives (PPA)

I suggest to join this with the buildstat bof+work below. Almost the same theme and the same people. --Ondřej

Debian needs something like Ubuntu PPA. Relevant links:

http://code.google.com/p/debppa/

http://wiki.debian.org/svnbuildstat

http://svnbuildstat.debian.net

The idea is to adopt the svnbuildstat package to work as a light server, that will accept source packages, and then there will be a set of buildbots, that will get a source package from the server, build it on a given architecture and upload back a binary package. In a similar way, lintian/linda/piuparts checks will be automatically handled. The result of this should be robust debian packages, that a user can easily use to create his own PPA. And someone with a server and a will can just install them and provide Debian PPA to others.

Participants:

[bof+work] {svn,git,ppa,whatever}buildstat

Presentation of the current svnbuildstat and the ideas for the next release.

Participants:

[bof+work] Overview of QA tools and results

Wiki page with pointers to all known QA tools and their results.

Participants:

[bof+work] piuparts: now and into the future

What's the current status of piuparts? What are its main shortcomings? What could be improved? How should it be developed in the future? Should it rely on qemu/xen for virtualization? Should it use plugins to implement tests? Should it have a comprehensive test suite to allow future modifications? Should it be more reliable about pass/fail status?

Participants:

[bof+work] mole: more data

Mole (http://wiki.debian.org/Mole) looks like a bit stalled (no more web interface?), but looks like one way to go to check package content across architectures (see outdated libtool, missing shared objects sometimes), and possibly correctness of dependencies.

Participants:

[work] user reviews of packages

(see discussion at the bottom of the page)

New service proposal. "I Like It".debian.net (or whatever): service for gathering user reviews of packages in the spirit of amazon book ratings/reviews. The idea is to couple a social-networking like site with some more Debian-like tools for collecting packages ratings and reviews (which motivate the ratings); in the second class of tools I imagine plugins for aptitude, command line tools, ... and so to submit reviews. If working, we can hope to achieve a useful addition to popcon which help in deciding which "suboptimal" packages should be better removed from our archive.

Participants:

[work^Wquick-hack] VCS Debian stats

How many packages are VCS-maintained in Debian?

I don't know if we all agree that a long term goal would be to have as much as possible of the Debian archive maintained on some VCS (I do agree on this), but nevertheless I would like to have some stats on how much of the archive is VCS maintained. On one hand this would help finding packages VCS-maintained but which are lacking VCS meta information. On the other it will help us monitor how the evolution of VCS-maintenance is going in Debian. I've some hackish tool to generate stats for Subversion maintained packages. I would like to extend those to support other VCS and set-up some stat-gathering script.

Participants:

[bof] Debian/Ubuntu collaboration on QA

How can Debian and Ubuntu collaborate on QA? A discussion would be nice.

Participants:

[work] Merge Debian, debconf, OFTC, turmzimmer.net branches of userdir-ldap

ud-ldap is used quite often now, so we should try to create a common repository, merge all different features and then use that repository together in the future.

Participants:

[Not very QA and probably not interesting to most people, but I'm abusing the schedule as my todo list here]

--- Add your idea here ---

Other stuff that could be discussed, with no specific talk/bof planned for now