David (bremner) is currently knocking together some beamer slides based on these notes. The past year has seen a lot of changes to how we handle the newest package maintainers in Debian. We have new software at mentors.debian.net, and a new process for handling them. This talk will begin by summarizing the current state of things (15 minutes), and then open up to a BoF where attendees can discuss the current state and what changes ought to be made, and how people can help. The topic of the BoF is about getting packages into Debian as a non-maintainer, and about the current process for mentoring non-uploaders through sponsored uploads to the Debian archive. The expected audience is a 50/50 mix of DDs and non-DD contributors to Debian. Changes in Debian over the past year: ===================================== In January Ansgar Burchardt, Jakub Wilk, Arno Töll and gregor herrmann proposed a sponsorship requests pseudo-package. Sponsorship requests are handled through bugs.debian.org since then. The severity on the bug is used to indicate if it relates to RC bugs, which frankly rules. WNPP-like bug titles are used to determine the type of a request Example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680141 * Discuss: Have people been enjoying this? Get feedback. * After half a year of practical experience people are undecided whether the idea yielded to an improvement. Control messages are mostly named when criticizing the new approach. This is, however, about to change and a new list dedidcated to sponsorship requests is being created and only actual requests and request answers are forwarded to mentors.debian.net ** Control messages: most people hate 'em. Asheesh likes just the "Closed" ones. Fix in progress (listmaster's action is pending). * Closing RFS bugs is one way of telling people early that their package is not sponsorable. Changes in Debexpo over the past year: ====================================== Active maintenance team: Led by Arno Toell and Nicolas Dandrimont, with contributions by 15 others in the past year. To reproduce this stat: Since the 2011-07-27 call for comments on expo.debian.net: debexpo git:(master) $ git log --since=2011-07-27 origin/improvexpo | grep ^Author | sort -u | wc -l 21 (note that 2 of these people contributed with 2 or 3 different email addresses *grunt*, and one is a dummy "Author" from the deployment account. More than half of those contributions were drive-by patches, and of course more help is always needed and wanted) Debexpo is now in wide use! What are its features? * All features the old mentors.d.n had (upload + manage Debian source packages) * Packages get removed when uploaded to unstable * Run QA checks when importing packages (Lintian, package type, bugs closed and more) The future: =========== Running GSoC projects with two students --------------------------------------- Clément Schreiner is writing automatic package <-> prospective sponsor matching heuristics * Analysis of packages uploaded to debexpo using, among others, debtags heuristics * Guess similar packages and prospective sponsors Baptiste Mouterde is improving the Debexpo package workflow * Integration of the sponsorship-requests pseudo-package into Debexpo * On-line Code browser with inline commenting * Two-way interaction with the debian-mentors mailing list (comments on the website <-> emails to a sponsorship-requests bugreport) * Integrate team-specific sponsoring - Team-specific sponsorship queues - Emails to team-"owned" packages could be redirected to the team's mailing lists - (When Clément's work pans out) automatic package <-> team matching Migration of mentors.debian.net into DSA infrastructure (i.e. making it mentors.debian.org) ------------------------------------------------------------------------------------------- This failed due to distributability questions in the past (packages uploaded to mentors are not guaranteed to be distributable). There is work in progress in collaboration with SPI lawyers to find a solution (which is likely to exist: DMCA safe harbor). Issues: ======= Comments, e.g. "I'm wondering how those .pc files ended up in that one" -- http://mentors.debian.net/package/kyotocabinet ^- Is this an example of a comment, or a question? :) .. and what's the context of it? This is a good example of a package contributor submitting work but indicating that he knows further work is needed. The comment is intended to be ethereal; once Shawn (in this case) knows why the warning on the site is being emitted -- AKA * Comments are incredibly unpopular but Baptiste's work may improve the situation a lot. Currently, I (db) never read comments on debexpo (how many people do?). Furthermore comments are deleted when the package deleted from debexpo. Both of these should be fixed by Baptiste's work. There is no history of uploaded packages (neither of previous user uploads) * This is being fixed as a side effect of Baptiste's GSoC work, where all the source packages uploaded are stored inside a git repository to keep track of their history (and allow for diffing between revisions). * Q: How useful is online diff? Sponsors should check this locally and not trust a web service. * UDD should also have a history of package uploads. The package namespace is shared among users (in a first-come, first-serve basis), which sucks. * The fix would only mean relaxing a database constraint and writing "disambiguation" page templates (i.e. "do you want to go to John Doe's package, or to Jane Foobar's package") Distributions (sid vs. experimental vs. s-p-u vs. ...) are poorly handled (and frankly I don't even know what happens when people upload packages for several distributions) * There is no control panel to manage packages and people, which means manual intervention (through scripts or database accesses) are often needed. Discussion: =========== Finding technical solutions for social problems ------------------------------------------------ Q: Why is sponsoring so extremely unpopular? Q: Why are non-DD upload permissions a complete mystery to many long-time contributors? Q: Do we need sponsoring? - Do we need packages or people? - Is a new package to work on one's own the right way to start? Q: What packages belong into Debian - See also the recent "scared away from your ITP dicussion" RFS bug related: ---------------- Q: Do attendees have any thoughts on the current bug driven process, either positive feedback or room for improvement? Q: Are there other specific work items that could improve ? Q: What are people's expectations, in terms of package quality, or in terms of expected latency? Q: Which packages belong into Debian? - When do we want to close RFS bugs which are unlikely to get sponsored _without_ scaring away people filing them - Who wants to maintain some stats on the bugs filed here? mentors.debian.net related: --------------------------- Q: Has debian-mentors seemed like a more welcoming place lately? Q: could mentors.debian.net be more attractive to _sponsors_? Q: Would sponsors use it to publish their own sponsorship-guidelines - Maybe show an example. Working code is there A copy & paste from the DebConf '11 sponsoring bof (move back above where/if applicable and current) ==================================================================================================== Q: How are we doing, what could we improve? ------------------------------------------- - wait times? - package quality? - telling people early their package is "not sponsorable"? - making sure RFS get any feedback (being acks or nacks)? - be fair to all requests? * requirements are different for different sponsors * find a bare minimum of requirements (e.g. think of "cdbs vs. debhelper", "traditional copyright vs. DEP-5", ...)? * waiting times are different * "luck" is a factor which does matter (e.g. fly-by mass sponsoring happens, where other packages are lost in space) - encourage non-DDs to do reviews (karma system for expo? related: see on expo.d.n for some review comments I made) - find a "fair" methodology to determine whether a package belongs to Debian or not? Q: Should there be a mentors team, or some other structure? ----------------------------------------------------------- - should sponsoring be a project priority, rather than just an individual developer choice? - what would it help exactly? - who would sign on for such a thing? - get more DDs to take care of sponsoring? Possibly relevant mailing list threads <8739be9ej1.fsf@deep-thought.43-1.org> <20120628144210.GJ14680@sliepen.org> <4F1802EF.7050001@toell.net> Minutes =========================== QUOTE: Bremner: Gobby is not emacs, it's so sad. Some statistics: * 18790 packages are in Sid, amongst which 3036 are non-NMU sponsored packages. If you use Debian, you are probably needing one of those; you probably rely on any of them. * 946 active DDs, 178 DMs, 906 sponsored people. OPINION: Bremner: There's a high barrier to be able to upload packages without a key in the /magic keyring/. OPINION: Bremner: Know packaging, love packaging, do packaging. This amount of work is the tiny part of getting packages sponsored. Bremner: sponsoring as a source for new contributors, not only about new packages; most of actual DDs have come to Debian trough getting packages sponsored, this shouldn't be underestimated as a source of future DDs. Bremner: There are DDs that sponsor, others that don't, various reasons undermine this. == The big picture == There is sort-of a "command-line" shock: debian-mentors{.*} is not anywhere close to Launchpad™. The Mighty Steps to Getting My Package Uploaded: * Prepare (Close your browser, open a terminal, GAAAAh !? ) * ITP (for new packages, reportbug wnpp) * go package (get help from #debian-mentors, feedback on your ITP [probably not positive]. * upload (well, sort-of) to mentors.debian.net : Upload, QA check, … * File a "Request For Sponsoring" (RFS) against sponsorship-requests. \o/ BTS fun * Wait, Revise, Wait, Revise, More Wait. This time the feedback is most probably positive. * Your Package Gets Uploaded™ (or not…) == "What packages belong in Debian ?" == It recently came as a surprise to some that "someone wants a new package to Debian but it might very well be that `Debian doesn't want it`…" ITP serves three roles: * Sanity check incoming packages * First contact of new contributions with the Debian community * Mutex to avoid multiple people working on the same thing. (less important in sponsoring context) The perception of ITP depends on the side: the filer says "here's the work I did, I propose it to Debian", while "debian-devel" (if that exists) understands it as "here's a new package `Debian` will have to maintain. Closing RFS's is another (fairly rarely used) feedback mechanism: make sure feedback is given out soon enough. == Tracking sponsorship requests in the BTS == After this experiment started, there has been been a lot more noise on the mailing list, but is planned to be improved. * 28 RC bugs fixed, 172 updates, 69? packages; quite a successful experiment. == Discussion == Q: Bottleneck in those steps ^ ? A: Not enough sponsors. I: Teams are not an administrative barrier, they are probably a resource. Q: Maybe we are not communicating / enforcing the needed commitment for new packages: in fact, the lifetime of a package is in measured in multiple years (unstable->testing->stable->security-> …). I: Removal of packages doesn't only carry a /technical/ cost, it does carry a human cost too (users, …). Q: Do the packages need to be in english? A: Not necessarily, but description and copyright probably need both for sponsors and FTP-Masters team.