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.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20423.24363.396379.966...@chiark.greenend.org.uk
