Re: "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
Reply to: