[pkg-php-pear] Orphaning php-codesniffer, then take it over by the PHP PEAR team

[Jonas Smedegaard]

On 12-05-30 at 09:41pm, Thomas Goirand wrote:
> On 05/30/2012 05:11 PM, Jonas Smedegaard wrote:
> > you use Debian freeze as argument for swift takeover. I find it not 
> > respectful to rush processing like that!
> >   
> 
> Again, no! That wasn't my point. My point was that it was left 
> unmaintained since the upload of 2008, which is 4 years ago.

A package can go untouched for several years and still be in good shape.

A package be messed with frequently and still be badly maintained.

For judging quality of maintainance it is better to look at handling and 
severity of bugs.


> So I will only do an NMU on the delayed queue, and leave one month 
> pass. Then if there's no reply, I'll ask for the package to be 
> orphaned.

If you fix grave bugs by doing an NMU, then you are responsible for 
maintaining your changes to the package - which means that if you do an 
NMU now just before freeze, it is highly likely that you will end up 
nursing those changes for several years to come.

...but those changes only! An NMU is an indication of you helping out 
the maintainer, not (in itself) an indication that the maintainer is 
failing to maintain.

Just sitting idle regarding this issue for a month doesn't sound 
sensible to me: Please consider checking our standard procedures for MIA 
handling. And please consider filing bugs for issues with the current 
packaging.

NB! The fact that code has not been updated to newest upstream release 
is in itself only of severity wishlist, but if newer upstream releases 
fix actual bugs it helps filing separate bugs about those.

Makes sense to revisit this discussion if, severe bugs have been 
reported, learning they are left unresolved.


> By the way, do other think that, even in this case, I should keep the 
> changes as minimum as possible? Or is it ok, considering that all of 
> our toolsets have changed since the last upload (eg: we now have 
> pkg-php-tools and dh 8 sequencer), that we do a bit more changes in 
> the package than just the new upstream release?

(I am not others, but...)

An essential point when NMU'ing is that you are *guest* maintainer.

Respect your host when visiting as a guest: Work in same style in 
expectation of your host having sane reasoning for the chosen style of 
maintainance.

Also, new tools do not necessarily mean better tools.

My couch is from IKEA.  I highly appreciate visitors to my home, but 
don't change the furniture - that's rude.  I use CDBS for my packaging.  
I highly appreciate help with my packaging, both ongoing as teamwork and 
drive-by as NMUs, but don't change packaging style - that's rude.

So yes, I think you should always keep changes minimal when doing NMUs.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20120530/b2e015b1/attachment.pgp>