"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_schedule/events/926.en.html
[2] http://meetings-archive.debian.net/pub/debian-meetings/2012/debconf12/high/926_Hijacking_packages_for_fun_and_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?

"Hijacking packages for fun and profit" BoF at DebConf
 

Dear debian-devel,

On Fri, Jul 20, 2012 at 07:24:15PM +0100, Steve McIntyre wrote:
> 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.

Thank you for conducting this, and to the video team for putting this
up. I have some follow-up questions and comments. If there is
something I am missing in what I say, or I am incorrect, please do
correct me.

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

Several of these might overlap, and some of these seem a little harsh
without additional qualifications. For instance, "not maintained how
you'd like" and "not packaged the way you would like it packaged"
aren't clear, although I can see where that would make a
difference (interdependent packages, convenient location of libraries,
scripts etc.). Similarly, "lack of uploads" makes sense only if there is
either a long divergence from upstream for no good reason. It might be
clear to those who are reading it, but I just felt happier qualifying
it the way I understand it.

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

A larger question which the project must address is that of
culture. How much of ownership over a package do you have? Would you
be offended if someone makes a change in your package which you
wouldn't approve of?

Now, if the change is prompted by someone who hasn't even waited a
month for the maintainer's response, then the maintainer has good
reason to be miffed about it. However, in the context of a hijack due
to delay, I'd say that the maintainer has lost a little of his/her say
in the matter owing to the long period of inactivity. This doesn't
(and shouldn't) reflect badly on that person; after all, it's a
volunteer driven project. However, if there is something in our
culture which makes the attachment to the package more technical than
emotional (i.e. "I package this library because I co-wrote it, or I
use it every day, or I am an expert" vs. _just_ "I packaged this
first, so I should have the final say"), I would love to learn about
it.

> 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?

My query with regard to this is whether the size of the problems it
solves far exceed the amount of bureaucracy it introduces. Ideally,
right from the NM process, we are asked what our "agenda" or ideal
contribution for Debian would be. Based on that, I can say with
reasonable assurance that you will not find me uploading glibc and gcc
tomorrow. However, since I had a grip on some other things, I could
help with NMUs (not really hijacks) for the gfortran transition some
years ago.

Why wouldn't a mere NMU be sufficient? Wouldn't enough affected
parties raise alarm bells if the NMU contains bogus fixes? I fear that
this might also dissuade people from going for an upload they aren't
convinced about. Then again, I might be totally missing the point! :-)

Thanks again!

Kumar
--
Not only Guinness - Linux is good for you, too.
-- Banzai on IRC


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120720214651.GB10512@bluemoon.alumni.iitm.ac.in" >http://lists.debian.org/20120720214651.GB10512@bluemoon.alumni.iitm.ac.in

"Hijacking packages for fun and profit" BoF at DebConf
 

On Fri, Jul 20, 2012 at 07:24:15PM +0100, Steve McIntyre wrote:
> Hi folks,
>

Hello,

I have not attended the "Hijacking packages for fun and profit" BoF at DebConf,
but I would like to share some thoughts on what I read in Steve McIntyre's
report.

It's a good title, that draws attention. :-)

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

The term "salvaging a package" sounds more positive than the more neutral
"taking over maintainership of a package". The more positive term may be
rather new, but the action is not new. I understand "salvaging" as just a
synonym for "taking over maintainership with good intentions".

I read the suggestion to "salvage a package" after one month of silence. That
does clearly not match the current MIA and NMU procedures. We should be
talking about improving/replacing the existing procedures, not about adding a
new procedure that contradicts with the existing ones.

I welcome a debate on making it easier to take over maintainership of a package
with objective criteria with shorter periods of time. But I really want to
reach a consensus on the criteria. I don't want people to go start "salvaging
packages" with the excuse that it's all with good intentions because
"salvaging" sounds so positive.

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

I think that "continued disagreement" is already the area of the TC, so I see
not much new there.

Let's not skip the role of the MIA team here. I suggest to give the MIA team
more power to forcibly orphan packages based on objective criteria, so that the
TC can rule over more exceptional cases that cannot be settled easily with
objective criteria.

I suggest to not use the term "hijack" when the MIA team or TC decide that a
package is orphaned.

>
> 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?

With all respect for the person suggesting the idea of "hijack tokens", I think
that this idea is not good. Some DD's have more eye to unmaintained packages,
and some DD's only look at their own packages. Handing out "hijack tokens"
clearly encourages the holder of the "tokens" to use them for "hijacking".

In my opinion, how I understand the term "hijack", an "hijack" is never OK,
because it is always possible to get consent from the maintainer, or from the
MIA team, or from the TC, or from a number of DD's seconding the "maintenance
takeover".

At this point I don't see enough reasons to limit or end the ability of any DD
to upload any package.

Other than all the above, I have read interesting ideas on objective criteria
in Steve McIntyre's report. Basically my point of this e-mail is that I
welcome a debate on changing the MIA and NMU procedures to introduce objective
criteria with short periods of time so that it becomes easier for anyone
interested to improve quality of packages in Debian.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120721065147.GB21283@master.debian.org">http://lists.debian.org/20120721065147.GB21283@master.debian.org

"Hijacking packages for fun and profit" BoF at DebConf
 

> Other than all the above, I have read interesting ideas on objective criteria
> in Steve McIntyre's report. Basically my point of this e-mail is that I
> welcome a debate on changing the MIA and NMU procedures to introduce objective
> criteria with short periods of time so that it becomes easier for anyone
> interested to improve quality of packages in Debian.

Taking over a package is not an NMU nor is it waiting for someone to be
completely MIA. An NMU is usually once for fixing bugs (so not updating
packaging, not moving it to another patch or revision control system and
the like). Being MIA is usually not even answering mails or IRC pings in
general for an extended time frame which is quite a bit further than not
caring about one package IMHO. Currently the MIA Team does not orphan
individual packages unless the maintainer agrees, so usually it's
orphaning all or none.

The normal procedure to take over a package should be consent with the
maintainer or the formal adoption procedure. Though I think it would be
good to also be able to take over a package without the need to declare
the maintainer MIA. One month without reply to an intent to take over
mail (or should that be bug report?) seems fair when the maintainer is
not on VAC (which usually is private), so I guess the devil is in the
details.

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 500A717F.6040409@debian.org">http://lists.debian.org/500A717F.6040409@debian.org

"Hijacking packages for fun and profit" BoF at DebConf
 

Hi,

> 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?

do we have statistics that show how many packages were really "hijacked" in such
a bad way that we would need to introduce some kind of token? I think we had
some rare cases over the last years which were discussed and solved. Do we
really need that extra work of introducing tokens?

Cheers,

Bernd

--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 500A75F6.6070101@bzed.de">http://lists.debian.org/500A75F6.6070101@bzed.de

"Hijacking packages for fun and profit" BoF at DebConf
 

On Sat, Jul 21, 2012 at 11:08:15AM +0200, Luk Claes wrote:
>
> > Other than all the above, I have read interesting ideas on objective criteria
> > in Steve McIntyre's report. Basically my point of this e-mail is that I
> > welcome a debate on changing the MIA and NMU procedures to introduce objective
> > criteria with short periods of time so that it becomes easier for anyone
> > interested to improve quality of packages in Debian.
>
> Taking over a package is not an NMU nor is it waiting for someone to be
> completely MIA. An NMU is usually once for fixing bugs (so not updating
> packaging, not moving it to another patch or revision control system and
> the like). Being MIA is usually not even answering mails or IRC pings in
> general for an extended time frame which is quite a bit further than not
> caring about one package IMHO. Currently the MIA Team does not orphan
> individual packages unless the maintainer agrees, so usually it's
> orphaning all or none.

Your point seems to be that we currently don't have a procedure for orphaning
individual packages.

>
> The normal procedure to take over a package should be consent with the
> maintainer or the formal adoption procedure. Though I think it would be
> good to also be able to take over a package without the need to declare
> the maintainer MIA. One month without reply to an intent to take over
> mail (or should that be bug report?) seems fair when the maintainer is
> not on VAC (which usually is private), so I guess the devil is in the
> details.

You seem to propose a light-weighted procedure to mark individual unmaintained
packages as orphaned (so that anyone interested can take over maintenance).

I propose the following for orphaning individual packages :

Anyone can mark a package as orphaned after the following steps have been
completed : Someone submits an "intent to orphan" in the bts with an
explanation of why he/she thinks that the package needs a new maintainer.
Anyone can submit this "intent to orphan". At least three DD's second the
"intent to orphan" on the same bug report with a cc to the maintainer. And the
maintainer does not respond within one month after the the third second.

Comments ?

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120721113915.GA10173@master.debian.org">http://lists.debian.org/20120721113915.GA10173@master.debian.org