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