On Thu, May 31, 2012 at 08:20:40AM +0200, Raphael Hertzog wrote:
> On Wed, 30 May 2012, Steve Langasek wrote:
> > There is no excuse for hijacking a package, ever.
> > If the maintainer is MIA, use the MIA process to get the package orphaned.
> This goes too far IMO. One of the reasons why the MIA process has been
> setup is because many DD fear forcibly taking over or forcibly orphaning
> a package. So instead of relying on random DD to do it, we put up some
> best practice procedure and a team to handle this.
> But this process is not set in stone, and if a DD believes that the best
> course of action is to orphan/take over a package, he should certainly be
> free to do it all by him/herself.
> Informing the MIA team for tracking purpose is still a good idea, though.
So I should probably clarify, because I misspoke in my previous message. By
"MIA process" I was not merely referring to the process used to determine
that a Debian developer is MIA and should have their account expired; I was
also referring to the longstanding process of discussing package orphaning
on the QA mailing list, and having the QA team make a determination that a
package is de facto maintainerless and should be orphaned.
The important thing here is still that the decisions are made by consensus
within the QA *team*, not as a decision by a single developer who decides to
take over the package. This is an important check on developers deciding in
the moment that their particular pet issue should trump our conventions.
So no, I stand by my statement that an individual DD should not take it upon
themselves to decide that a package should be orphaned. This sort of thing
needs to be a community decision.
On Thu, May 31, 2012 at 01:08:11PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team"):
> > A hijack is, by definition, a declaration by the hijacker that they believe
> > they are not answerable to the project's processes for how package
> > maintenance is decided. It is antisocial vigilanteism and it is not
> > acceptable.
> Our processes for how package maintenance is decided are utterly
> dysfunctional.
> If the TC had _ever_ voted to remove a maintainer who wanted to keep
> hold of a package, it might be at least reasonably possible to argue
> that the TC was the right forum for these disputes.
> > As a sitting member of the Technical Committee, I encourage anyone who sees
> > a package being hijacked to immediately bring it to the attention of the TC.
> > I will without hesitation vote to have the hijacker barred from being made
> > the maintainer of the package.
> Instead of this kind of aggressive approach to those who are IMO quite
> reasonably working around our dysfunctional formal processes, how
> about working towards fixing those dysfunctional processes ?
> I await with interest your suggestions for revising the way the TC
> deals with problematic maintainers. I have been arguing for years
> that we need a much more robust approach.
Right, so the constitution says that it's the TC that decides whenever
there's a question of maintainer.
But in practice, when one of the would-be maintainers is not doing the work
and not responding to email, I don't think there should be any need for the
formal process of a TC vote. I think it's more than sufficient to get a
consensus on the mailing list that the maintainer isn't coming back, *after*
making an appropriate effort to contact the maintainer and waiting a
suitable amount of time for a response. And indeed, this is the convention
that's been in place for approximately the past decade on the debian-qa
list.
The key points of this process are:
- It's not a decision by an individual that the package can be orphaned
(and silence does not imply consent).
- An effort is made to actively contact the maintainer on the subject of
orphaning, rather than assuming the maintainer's non-interest based on
the state of bugs.
- The maintainer is given a suitable amount of time to respond. A week is
not a suitably long waiting period. Indeed, the minimum waiting period
here should *at minimum* be longer than the longest NMU waiting period.
- The orphaning does *not* go ahead over the maintainer's objection. If
the current maintainer objects, they should be persuaded by reasoning or
the matter should be referred to the TC.
This is very different from what some people mean when they use the word
hijack. In part, I think we have a terminological problem here; I don't
know if it's a matter of non-native speakers using the word differently, but
the word "hijack" clearly refers to a /hostile act/. By definition,
anything that could legitimately be called a hijack should not be permitted;
and anything that we believe should be permitted should not be referred to
as "hijacking". Otherwise, people will infer that all kinds of
inappropriate and hostile behavior is ok when it shouldn't be.
And when people *do* engage in that kind of hostile behavior, yes, I think
it should be referred to the TC and we should disapprove of it. But when
people are taking reasonable steps to confirm that a package is abandoned
before taking it over - let's call this "salvage" - I have no problem with
that; it should be encouraged and supported.
As for the TC never having removed a maintainer against their will: I think
the TC is institutionally conservative by design, and will tend to favor the
status quo in such matters. It's not enough to establish that one developer
would be a better maintainer than the other; the question is whether the
difference is so great that it justifies demotivating the current
maintainer. I don't think the fact that the TC has yet to say "yes" to this
question is evidence of a broken process.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature