Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 06/01/2012 08:45 PM, Steve Langasek wrote:
> 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.
That is exactly what the MIA team does (or should do but sometimes just doesn't
find the time to do so). There is no formal QA team.
> 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.
Everybody is part of the QA team, there are only some people with write access
to the repositories, that is the only difference. As I mentioned before (see my
other mails in this thread) such discussions happened for years on debian-devel
(or on debian-qa, but that does not make a difference), and not somewhere in a
QA "team".
> 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.
What do you think why the original submitter wrote to debian-devel?
> 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.
Why on debian-qa? It is a long tradition to post such requests to debian-devel,
and most people read this list. I can't see a reason why it should be posted to
-qa, especially not as there is no special QA team.
> 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.
In case of hostile behaviors there is also an active maintainer which is able to
refer such cases to the TC by himself, there is no need to crowd-source this.
> 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.
>
--
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
Reply to: