"Hijacking packages for fun and profit" BoF at DebConf

Hi folks,

Here's a summary of what we discussed in the BoF [1] last week (12th
July). Thanks to the awesome efforts of the DebConf video team, the
video of the session is already online [2] 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[3] 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[4].

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.

[1] http://penta.debconf.org/dc12_sched...26.en.html
[2] http://meetings-archive.debian.net/...profit.ogv
[3] http://wiki.debian.org/qa.debian.org/removals
[4] http://udd.debian.org/cgi-bin/bapase.cgi
Steve McIntyre, Cambridge, UK. steve@einval.com
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?






To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120720182415.GC11301@einval.com