The graph below is generated from popcon submissions. Since they include the version of the popularity-contest package, one can determine the Debian release that was used by the submitter (a new version of the popularity-contest package is generally uploaded just after the release to make that tracking possible).

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.

After one week of campaign on -vote@, many subjects have been mentioned already. I’m trying here to list the concrete, actionable ideas I found interesting (does not necessarily mean that I agree with all of them) and that may be worth further discussion at a less busy time. There’s obviously some amount of subjectivity in such a list, and I’m also slightly biased ;) . Feel free to point to missing ideas or references (when an idea appeared in several emails, I’ve generally tried to use the first reference).

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.

(Looking for those graphs online, I realized that I never properly published them, besides that old post)

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).

When Francesca started her DPL game, I too started think about possible candidates. Here is my shortlist of dream candidates:

• <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.)