[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

On 05/31/2012 08:43 PM, Jonas Smedegaard wrote:
> I have no intention of spreading or amplifying wrong information.
> Do I understand it correctly that your intention in your original 
> post was to have the package orphaned and then have a team take over 
> maintainance?

I was also pointing out that the package was anyway badly
maintained, and that in such case, we have to do something
about it.

There are things that I omitted, because I thought that it wasn't
necessary. For example the fact that Jack Bates didn't reply to
#599617 (bug opened on the 9, Oct, 2010), #634825 (bug opened
on the 20, Jul 2011), and #470294 (opened on the 11, Mar 2008)
shows how little care...

My goal was to ask if it was ok to start the MIA procedure after a week
only, and not wait a full month, because it seemed obvious that the
original maintainer was MIA.

The more the time passes, the more I think I was right, because Jack
Bates continues to be MIA. I still hope I'm proven wrong though, and
that our Jack friend will wake up, but there's not much chance
anymore that this happens...

I don't call this a will to hijack a package, but asking for advices on
how to the situation of this unmaintained package.

> Do I understand correctly that your intention in your original post was 
> (after having tried to reach the maintainer for 5 days and having 
> noticed that others have tried for several years) to have the orphaning 
> occur without the consent of the maintainer?

I was asking if it was alright to ask the MIA team to orphan the
package, yes, because no reply from Jack. Never I wanted to do
it myself, or take over the package without going through the
standard procedures.

I also think that even if the original maintainer replies now,
he's not fit for the job (not enough reactivity, not enough
maintenance of his package), and that if he feels like willing
to continue contributing to Debian with this package, then
the best option is to join the PKG PHP PEAR team, and
collectively maintain the package.

Note that there's really enough work on the PEAR packaging
so that other member can join. Have a look here:


There's 45 packages. Out of them, I was the one who uploaded
them all lately, apart from 4 of them: php-crypt-blowfish,
php-net-dnsbl, php-text-wiki, php-xml-rpc and php-net-seive.

That's 40 packages that I've been working on before the
freeze (some of, phpunit related, with the help of Luis)!
Yes, they are easy to maintain, but somebody has to do
the job still.

We've also added phpunit to the archive and I've added
unit tests at build time for 9 of these packages to make sure
that no mistake is introduced, and that they are functionally
working. That's by the way one of the addition I would have
liked to add to this package: running the 210 unit tests that
it has...

I believe I have made a good job maintaining all of these PEAR
packages (but I am of course open to critics and improvements).
I also believe that I deserves the right to be critic of other PEAR
packaging when I see issues, after all this time I invested
keeping all of these up-to-date and in good shape.

php-codesniffer is a tool to make sure that PEAR packages
are using the coding standards. It's one tool that will help
increasing the overall quality of all of these PEAR packages
as well, just like PHPUnit does. It makes me sad to see it
the way it is in Debian, and I wanted to fix this.

Now, you are calling this a "hijack" ... It really
doesn't feel right on my side to read such wording. :(

Gosh, do I really need to write all this to explain myself?
This is a horrible waste of time Jonas...


Reply to: