The graph is similar to the one found on popcon, except that versions newer than the latest stable release are aggregated as “testing/unstable”.

Comments:

• Popcon submitters might not be representative of Debian users, of course.
• There’s quite a lot of testing/unstable users, and their proportion is quite stable:
  • Today: testing/unstable: 43119 submissions (31.4%); squeeze: 75454 (54.9%); lenny: 13603 (9.9%)
  • 2011-02-04 (just before the squeeze release): testing/unstable: 29012 (29.7%); lenny: 57262 (58.6%); etch: 10032 (10.3%)
  • 2009-02-13 (just before the lenny release): testing/unstable: 30108 (36.9%); etch: 49996 (61.2%)
• I don’t understand why the number of Debian stable installations does not increase, except when a new release is made. It’s as if people installed Debian, upgraded directly to testing, and switched back to tracking stable after the release. Or maybe people don’t update their systems? A more detailed analysis could be done by looking at the raw popcon data.
• Upgrading to the next stable release takes time. Looking at the proportion of users still using oldstable one year after the release, it would be better not to remove oldstable from mirrors too early.

Scripts are available on git.debian.org.

On the campaign itself, and having general discussions inside Debian:

• have those discussions on a more regular basis, outside DPL elections (from lucas)
• use polls to measure consensus (from lucas, question from mjr)
• use a pre-arranged questionnaire that DPL candidates would fill in (from algernon)

On getting new users and contributors to Debian:

• discussion on the various steps: Debian user – first contribution – regular contributor – DM/DD (from lucas)
• maintain a single list of “paths in” (from moray and lucas)
• have some “neutral” people to ask about tasks, and to get suggestions from in response to explaining their current skills and experience (e.g. http://www.debian.org/women/mentoring) (from moray)
• more local meetings, compile list of regional contacts (moray)
• increase Debian presence at local meetings. Advertise the Debian Events initiative that facilitates that (from lucas)
• provide “Debian ambassador” title for students, similar to what is done by Google or Microsoft (from moray)
• re-work on advertising gift tags (bugs suitable for new contributors) (from lucas)
• make sure teams have list of easy tasks in their wiki pages (from lucas)
• discussion on student projects involving Debian (from lucas)
• do mentoring inside teams, like DebianMed’s MoM (from moray)
• participate in other internship-like programs, like Outreach Program for Women (link from lucas), or organize our own, which would also avoid some restrictions from GSoC (northern hemisphere only (point made by moray), restricted to students (ana))
• extend internship-like programs to other kinds of work (packaging, documentation, etc.)
• localize -mentors@ (mailing lists + IRC channels for DE, FR, ES contributors) (from lucas)
• organize IRC schools/seminars about e.g. packaging (from lucas)
• introduce more gamification in mentoring (from rra)

Infrastructure, processes, releases:

• improve infrastructure to help with team maintenance (e.g. PET) (from lucas)
• authorize NMUs for archive-wide changeovers such as /usr/doc -> /usr/share/doc  (from moray)
• increase visibility of RC bugs squashers by listing them in Debian Project News (from lucas)
• provide inexpensive non-monetary gifts (free t-shirts?) to RC bug squashers (from lucas)
• re-open discussion on gradual freezes (from lucas), focus attention on more important packages by improving tools (from lucas) and removing packages earlier (from moray and lucas)
• involve upstreams and downstreams in RC bug fixing (from algernon)

Relationships with upstreams/downstreams:

• use Debian money to sponsor maintainers to attend upstream events (from lucas)

This list could be moved to wiki.d.o if others find sufficiently useful to help maintaining it.

I’ve been playing with snapshot.d.o, which is a fantastic resource if you want to look at Debian from an historical perspective (well, since 2005 at least).

Team maintenance

We now have more team-maintained packages than packages maintained by someone alone. Interestingly, the “small, ad-hoc group of developers” model does not really take off.

Maintenance using a VCS

A large majority of our packages are maintained in a VCS repository, with Git being the clear winner now.

Possible goal for Jessie: standardize on a Git workflow, since every team tends to design its own?

Packaging helpers

Again, we have a clear winner here, with dh. It’s interesting to note that, while dh was designed as a CDBS killer, it kind-of fails in that role.

Possible goal for Jessie: deprecate at least pure-debhelper packaging?

Patch systems and packaging formats

Again, clear winner with 3.0 (quilt).

The (dirty) scripts that generate those graphs are available in Git (but you need to connect to stabile to execute them, and it’s rather time consuming — hours/days).

• <insert your name here>
• <or here>
• <or there>
• <or even there>

Seriously, if you are a DD, you have the right to run. There’s no need for someone to nominate you. If you think that you could possibly say something interesting during the discussion period, and can spare the time to participate in the -vote@ discussions, please run. DPL campaigns used to be a great time where Debian visions, goals, politics and random stuff were discussed. The more candidates, the more interesting campaigns (8 candidates in 2007!).

Also, there are already two three other candidates, so even if you don’t want the job, it’s not that risky.

(Initially, I thought about nominating everyone, but security-wise, it might not be such a great idea.)

However, using a few UDD queries, I could come up with:

• 3147 packages out of 18649 packages in sid (17%) were last uploaded using a sponsored upload.
• There are 963 distinct sponsorees, vs. a total of 2015 distinct emails in the Changed-By field of packages in sid. Given that it’s more likely for DDs to have used several emails to upload packages, it’s very likely that half of the package maintainers are sponsored maintainers.
• There are 2185 packages without a DD in either the Maintainer: or the Uploaders: fields. (That includes some packages that are maintained by a team that could include some DDs)

Full UDD notes:

all packages in sid:
select source, version from sources_uniq where release = 'sid'

packages in sid known to upload_history:
select source, version from upload_history where
(source, version) in (select source, version from sources_uniq where release = 'sid')

packages that were uploaded by the changed_by person:
create temporary table sources_not_sponsored as select distinct source, version
 from upload_history, carnivore_keys, carnivore_emails
 where (source, version) in (select source, version from sources_uniq where release = 'sid')
 and fingerprint = key
 and carnivore_keys.id = carnivore_emails.id
 and carnivore_emails.email = changed_by_email;

packages not uploaded by the changed_by person:
create temp table uh_sid as select source, version, fingerprint, changed_by_email
from upload_history
where (source, version) in (select source, version from sources_uniq where release = 'sid');

create temp table uh_sid_sponsored as select source, version, fingerprint, changed_by_email from uh_sid
where (source, version) not in (select source, version from sources_not_sponsored);

list with sponsor login:
select distinct source, version, fingerprint, changed_by_email, login
from uh_sid_sponsored
left join carnivore_keys on fingerprint = key
left join carnivore_login on carnivore_keys.id = carnivore_login.id;

=> 4188 sponsored packages. some of them are in a strange state (changed_by is a DD, but uploaded by another DD). excluding those:

create temp table sponsored_but_dds as select distinct source, version, fingerprint, changed_by_email, login
from uh_sid_sponsored, carnivore_emails, carnivore_login
where changed_by_email = carnivore_emails.email
and carnivore_emails.id = carnivore_login.id;

create temp table really_sponsored as select distinct source, version, fingerprint, changed_by_email, login
from uh_sid_sponsored
left join carnivore_keys on fingerprint = key
left join carnivore_login on carnivore_keys.id = carnivore_login.id
where (source, version) not in (select source, version from sponsored_but_dds);

=> 3147 sponsored packages

select distinct changed_by_email from really_sponsored ;
=> 963 different sponsorees

select distinct changed_by_email from upload_history where
(source, version) in (select source, version from sources_uniq where release = 'sid');
=> 2015 distinct emails.

no DD amongst maintainer or uploader:

create temp table dds_emails as select email from carnivore_emails, carnivore_login
where carnivore_emails.id = carnivore_login.id;

select source, version, maintainer, uploaders from sources_uniq
where release='sid'
and maintainer_email not in (select * from dds_emails)
and not exists (select * from uploaders where release = 'sid' and sources_uniq.source = uploaders.source and sources_uniq.version = uploaders.version and email in (select * from dds_emails))
and maintainer_email != 'packages@qa.debian.org'
and (source, version) in (select source, version from really_sponsored);

The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 916
  • Affecting wheezy: 464
    That’s the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting wheezy and unstable: 327
      Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 77 bugs are tagged ‘patch’.
        Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 17 bugs are marked as done, but still affect unstable.
        This can happen due to missing builds on some architectures, for example. Help investigate!
      • 235 bugs are neither tagged patch, nor marked done.
        Help make a first step towards resolution!
    • Affecting wheezy only: 137
      Those are already fixed in unstable, but the fix still needs to migrate to wheezy. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.

Note: I’m looking for someone to send this posts on a regular basis. All you need is a blog syndicated on Planet Debian (there’s a secret UDD page that generates the HTML code for you ;) ). Contact me if you are interested. taken!

Done:
- added tabs (jquery really rocks) — see example
- added a hacking.html file that describes how to setup a development environment
- created a pad (http://debian.titanpad.com/DMD) to store ideas.

TODO:
- recruit contributors ;)

The idea is to expose as much useful information as possible about a maintainer’s packages, both in the traditional (Developers Packages Overview-like) “big table with all the info”, but also in a task-oriented listing (to answer the “ok, I have two hours for Debian, what should I do now?” question).

At this point, the Debian Maintainer Dashboard already brings several cool features (try it with my packages or pkg-ruby’s packages, or your own!):

• Reports buildd issues (failed builds)
• Upstream status monitor that works (UDD has its own)
• Knows about teams’ VCS (if your team uses PET) and display the current version in the VCS
• Lists packages you maintain or co-maintain, and also the package you showed interest for by subscribing to them on the PTS

Of course, as of now, it’s pretty ugly: that’s the “help needed” part of the post. I really suck at web design, and would really appreciate if someone would help me to turn it into something nice to use. Besides adding links and colors everywhere, it could probably be nice to add sortable tables, and to create tabs for “TODO items”, “Versions” and “Bugs” (and possibly Lintian, for example). Contact me if you are interested.

Since 2007, I had been running Debian archive rebuilds on the Grid’5000 testbed, a research infrastructure for performing experiments on distributed systems – HPC/Grid/Cloud/P2P. I filed more than 6000 release-critical bugs in the process.

Late last year, Amazon kindly offered us a grant to allow us to run such QA tests on Amazon Web Services. With Sébastien Badia, we ported the rebuild infrastructure to AWS (scripts), and several rebuilds have already been carried out on AWS.

On the technical level, 50 to 100 EC2 spot instances are started, and then controlled from a master instance using SSH. On build instances, a classic sbuild setup is used. Logs are retrieved to the master node after rebuilds, and build instances are simply shut down when there are no more tasks to process. Several tasks are processed simultaneously on each instance, and when they fail, they are retried again with no other concurrent build on the same instance, to eliminate random failures caused by load or timing issues. All the scripts are designed to support other kind of QA tests, not just rebuilds.

Moving to Amazon Web Services will facilitate sharing the human workload of doing those tests. It is now possible for developers interested in custom tests to do them themselves (hint hint).