Hi folks, Here's a summary of what we discussed in the BoF  last week (12th July). Thanks to the awesome efforts of the DebConf video team, the video of the session is already online  in case you missed it. I've also attached the Gobby notes that were taken during the session. I'd like to express my heartfelt thanks to the people who took part - we had a very useful and productive discussion on a potentially very controversial topic. It would be good to continue the discussion with a wider audience. Package maintainership and ownership ==================================== The concept of package maintainership is central to Debian. It's one of Debian's biggest strengths, in that we can delegate technical decisions about packages to expert individuals or small groups of maintainers. They can then do their work and make things happen without having to seek approval of the whole project for every change they make. The flip side of this is that package maintainership can also be a problem: maintainers can be too territorial about "their" area and block development when they're inactive or disagree with proposed changes. It can often get in the way of the "do-ocracy"; if a maintainer does not have the time or inclination to work on their package, they can still stop other people from doing it. What is hijacking? ================== There are cases where we need to balance maintainer control against wider requirements. Two different issues here. * taking over a package where the existing maintainer agrees or is missing/MIA * taking over a package where the existing maintainer objects To help distinguish them, let's call the first of these "salvaging". Salvaging --------- If an existing maintainer seems "clearly" not to be maintaining a package, then it should be simple to assume maintainership. Mail that maintainer asking if they would be happy with this, and give a reasonable length of time (suggestion: 1 month) to respond. If (ideally) they respond positively or (less ideally) there is no response, then it should be considered sensible to take over the package. If the existing maintainer objects, then continuing on becomes a hijack. The explicit concept of *salvaging* seemed to be new in this discussion, and was generally agreed to be a good way of thinking about the problem. Hijacking --------- If there is continued disagreement over who should be the maintainer here, or (more generally) how maintenance should be done, then rather than simply argue endlessly and cause bad blood a good option should be to take it to the Tech Committee for a ruling; they are the correct body to arbitrate here. Ian was very much in favour of this, even if he was worried the rest of the TC might be less happy... :-) There was also talk of a GR to explicitly ask the TC to take more aggressive control in this area. What makes a package ripe for salvage / hijack? =============================================== Many reasons suggested: * if a package is *un* maintained? * if a package is *badly* maintained? * if a package is not maintained how you'd like? * if the maintainer is MIA? * if the Tech Committee say so? Claimed that the Tech Committee have never explicitly handed over a package as a decision, although apparently lilo maintainership was decided by the RC * lack of uploads * RC buggy without comment Or -- interestingly -- RC buggy, and bug is closed without comment on the particular bug * not packaged as you would like it packaged * the maintainer is a bully towards bug reporters? (i.e. misbehaves) (So package is maintained, just... hurtfully) Different people have widely differing opinions here. Could we / should we come up with a metric or a formula or a set of flags to indicate that a package is "in trouble"? Even if agreed and possible to do this well, it's difficult to do this strictly; it would be far too easy to game criteria. Should orphaned packages be considered RC-buggy and removed from testing during a freeze? A common concern during the discussion was that in general people are wary of making this kind of decision; hijacking and package removals can easily become controversial as maintainers feel ownership or even emotional attachment. Vince suggested that policy should be updated to describe hijacking and salvaging more explicitly, and was promptly volunteered to do that. *How* to hijack? ================ Orphaning/removal ----------------- Via the QA team, packages can be orphaned. The process is not as well-understood as it might be; opinions are divided as to how things may be done. Is a removal the same as a hijack or salvage? There's technically nothing to stop people from "removing" a package then immediately uploading a new version with themselves as maintainer. Aside: the QA team also maintain a list of packages with a variety of problems that could be ripe for removal. Hijack tokens ------------- At the moment, *any* uploading DD can hijack by simply uploading a new package version. Is that reasonable, or should we attempt to control it somehow? There was a concept suggested of "hijack tokens" - an idea that maintainers should be allowed to hijack packages so long as they show sense. Only one hijack would be allowed per DD by default, with maybe more tokens being allocated depending on age / experience / responsibility within the project. The tokens could be allocated to developers by the Tech Committee, or maybe restored after review once a hijack has happened. Potentially problematic, but maybe a useful idea for discussion? Related ======= Extra information / help from the BTS/PTS might be helpful for us. WNPP bugs could "affect" the main package or the BTS could automatically list all O:, RFH: and RFA: bugs for that package. Also, we could start filing these bugs in the package itself instead of WNPP, and use usertags for discovery.  http://penta.debconf.org/dc12_schedule/events/926.en.html  http://meetings-archive.debian.net/pub/debian-meetings/2012/debconf12/high/926_Hijacking_packages_for_fun_and_profit.ogv  http://wiki.debian.org/qa.debian.org/removals  http://udd.debian.org/cgi-bin/bapase.cgi -- Steve McIntyre, Cambridge, UK. firstname.lastname@example.org We don't need no education. We don't need no thought control.
== Hijacking packages for fun and profit == Please take notes here Controversial topic! What do we mean by "hijack"? How to balance maintainer control against wider requirements? Can include situations where maintainer is just absent - use MIA. * 'salvaging' Is it only a hijack if the existing maintainer objects? What time limits need to be applied between stages? Narrow the scope to where an existing maintainer actively objects to a transfer. * blocking and removing from testing orphaned packages during a freeze. - escalating O: bugs to RC. * nobody wants to be the one left with the decision, except the adjutant. Less contentious are changes of maintainer or changes which can reasonably take a significant amount of time. A series of indications / flags - not strict criteria on which a _must_ rule can be implemented. Hijack token - the number of times a particular maintainer can do a hijack. * given out by the TC or to restore them afterwards? * TC GR - should TC be more or less aggressive. WNPP bugs could "affect" the main package or the BTS could automatically list all O:, RFH: and RFA: bugs for that package. Also, we could start filing these bugs in the package itself instead of WNPP, and use usertags for discovery. Is it *ever* right to hijack? * if a package is *un* maintained? * if a package is *badly* maintained? * if a package is not maintained how you'd like? * if the maintainer is MIA? * if the TC say so? Tech Committee have never explicitly handed over a package as a decision. (lilo maintainership was decided by TC) * lack of uploads * RC buggy without comment Or -- interestingly -- RC buggy, and bug is closed without comment on the particular bug * not packaged as you would like it packaged * the maintainer is a bully towards bug reporters? (i.e. misbehaves) (So package is maintained, just... hurtfully) Different people have widely differing opinions here, so what's right? Can we agree some guidelines? Existing QA guidelines (on removals and orphaning): http://wiki.debian.org/qa.debian.org/removals * is a removal the same as a hijack or salvage? * QA bapase : http://udd.debian.org/cgi-bin/bapase.cgi * How about hijacking ITPs/ITAs, etc?
Description: Digital signature