Better to improve our sponsorship workflow?

I recently sponsored several uploads, and was asked to sponsor even more uploads, and that got me thinking about our sponsorship workflow. It’s a clear bottleneck in Debian, and discourages many new contributors, which obviously sucks.

It’s important to note that the same problems exist in Ubuntu (their equivalent to is named REVU).

The best way to improve the process would be to have packages of better quality when a DD first look at them. They would be more likely to be uploaded right away, which frees time for other packages. I think that there’s a lot of room for improvement in the current implementation. Here is a small list of features I would like to see.

  • Integration of some QA tests in mentors, as soon as the package is uploaded:
    • does the package build cleanly?
    • piuparts test?
    • lintian/linda checks?
  • Better list of packages awaiting sponsors, with info including:
    • does the package fixes bugs (number of bugs fixed per severity)?
    • is that package already in Debian?
    • is that package a new upstream version?
    • popcon score
    • how long has the package been waiting?

    This would allow potential sponsors to prioritize requests.

  • A commenting system, for each package, so comments for rejected packages are not lost, and the next potential sponsor can double-check
  • A way for sponsors to mark some sponsorees as “friends”, so it’s easy to find all the requests from people I “trust” (for some definitions of “trust” ;)
  • Maybe, a scoring system, where providing good comments on other’s packages would make you win “karma points”, and improve your classification, which could later be used by sponsors to choose what they are going to sponsor next.

The good thing with this whole list of features is that everybody can help. So, if you are looking for a sponsor and want to help solve this problem, start coding now ;) And if you need me to create, just ping me. There’s probably some code to steal from, so contacting its developers would be a good idea.

10 thoughts on “Better to improve our sponsorship workflow?

  1. I totally agree with you. How can you think this could be implemented?
    I don’t know the existent structure of mentors or svnbuildstat, so my guess could be a combination of php+mysql or something similar.

  2. We haven’t talked on IRC about and potential improvement or have we? Because your list is pretty close to the todo list in front of me regarding the undergoing redesign of the mentors website. :) And I think I talked it over a few times already on #debian-mentors. Anyway. will get a facelift although I don’t know how long it will take. Perhaps something for christmas.

    Above all the mentors site will work more like a social networking site (we all know that kind) so that human interaction is made simpler. I’m sometimes pointed at bad package maintainers but so far you can do little about it because everybody is free to upload any package. Commenting, scoring and keeping contacts will be an integral part of the new site. More comfortable interface of course because I know the package list sucks. The interface comes from the time (2 years ago) when the interest was lower than today. Getting informed when your (in case you are a DD) sponsorees upload new versions. Stricter checking (e.g. no more overwriting of packages carrying the same revision number). Linda and lintian checks are done already. I’m not sure that I want to make it a buildd and install a complete build system just to check if a package with dozens of dependencies builds correctly. Some fun should be left to the sponsor, too. :)

    Better connections to the BTS (via the LDAP interface)… the list is pretty long. I think I’ll publish the current list on so that people can help me think about the feature list and maybe add their ideas.

    Although however I think that has come a long way and is already a nice site with a lot of automagic. Even if it may appear simple to the users of it. There’s a lot going on under the hood for verification, watching the debian-devel-changes list, lintian checks, native package checks etc.

    Christoph (running the site)

  3. Hi,

    I share your point of you. I already did some changes on svnbuildstat.d.n database schema to store build result from other type of package repositories and with Ondrej Certik we want to improve the agent too.

  4. I wrote almost the same into the mentors list (see the links at debppa) but I got almost no response, so I thought no one is interested in that. But now I know many people want this – so I was just using a wrong communication channel probably.

  5. Another idea: automatically remove a package when a package of that name with a same or newer version is/comes available in sid.

  6. random check to add:
    check that all bugs closed by the package actually belong to the package. This bites everybody at least once :-)

  7. I think mentioning Ubuntu’s REVU is good. It is similarly in need of improvement. It would be nice to see if it would be possible to collaborate on a common successor system.

  8. Pingback: Lexapro.

Comments are closed.