FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-29-2012, 07:51 PM
Jonas Smedegaard
 
Default Orphaning php-codesniffer, then take it over by the PHP PEAR team

On 12-05-30 at 02:49am, Thomas Goirand wrote:
> Jack Bates is supposed to maintain php-codesniffer,
[snip]
> this package last upload was from 2008-10-05,
[snip]
> we'd like to see the latest version in Wheezy
[snip]
> We sent a mail 5 days ago to Jack Bates, and he didn't reply. It's
> currently obvious that there's very few chances that Jack Bates will
> upload a new version of php-codesniffer before Wheezy freezes.
>
> So, we'd like to have php-codesniffer orphaned, then taken over by us
> (eg: the PKG-PHP Pear team). Jack Bates would anyway be very welcome
> to join the team, and continue to do his packaging (we can add him to
> the Uploaders: list if he wishes), even after this procedure.
>
> So, if nobody objects within the next following 2 or 3 days, and if
> Jack doesn't show up and oppose to this procedure, we'll do that.

I strongly object to this as a general principle: Debian freezing is no
excuse for hijacking!

Seems you had several years of solving this issue, yet you waited until
just before freeze, and the option you came up with was to kick a
maintainer.

Did you consider an NMU?


- Jonas

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

[x] quote me freely [ ] ask before reusing [ ] keep private
 
Old 05-29-2012, 08:54 PM
Arno Töll
 
Default Orphaning php-codesniffer, then take it over by the PHP PEAR team

Hi,

On 29.05.2012 21:51, Jonas Smedegaard wrote:
> Seems you had several years of solving this issue, yet you waited until

Similarly, the maintainer had 4 years to care about his package.

> Did you consider an NMU?

That might be an alternative, but looking at the current bug list people
will argue about the lacking ground to base a NMU on. It does not really
qualify as a typical NMU candidate.

People shouldn't be (so) afraid to hijack and NMU packages if they take
care of virtually unmaintained packages. There is nothing to apologize
or feel sorry about when improving Debian's overall quality.

Having that said, 5 days of (private) conversation is perhaps really a
bit too short to hijack a package. I'd expect that process to include
several weeks of waiting time for an answer at least.

Therefore I can see good reasons to hijack such a package. But not in
such a hurry. If you really care enough, do a minimally invasive but
clearly hostile NMU to start with and give the maintainer a reasonable
time frame to respond.

Do also CC the MIA team in your conversations, there are other packages
Jack maintains which are long outdated and were NMUed already.

--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
 
Old 05-29-2012, 11:45 PM
Charles Plessy
 
Default Orphaning php-codesniffer, then take it over by the PHP PEAR team

Le Tue, May 29, 2012 at 10:54:32PM +0200, Arno Töll a écrit :
>
> Having that said, 5 days of (private) conversation is perhaps really a
> bit too short to hijack a package. I'd expect that process to include
> several weeks of waiting time for an answer at least.

I concur. It is socially and technically safer to give about two week-ends to
answer, keeping time zones in mind. If after this delay you have no news, my
opinion is that hijacking is the best solution. The maintainer's other
packages have already attracted three NMUs in total, and I have not seen a bug
report with his answer after 2009 (although got some packages sponsored in
2011). By the way, perhaps you can keep his sponosor (rmgolbeck) in the loop,
maybe he knows other ways to contact the maintainer ?

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120529234522.GA479@falafel.plessy.net">http://lists.debian.org/20120529234522.GA479@falafel.plessy.net
 
Old 05-30-2012, 03:30 AM
Thomas Goirand
 
Default Orphaning php-codesniffer, then take it over by the PHP PEAR team

On 05/30/2012 03:51 AM, Jonas Smedegaard wrote:
> I strongly object to this as a general principle: Debian freezing is no
> excuse for hijacking!
>

That's not the reason, the reason is that we've been working on tools to
improve
PHP package quality, and recently noticed that php-codesniffer was left
largely
unmaintained since 2008.

> Seems you had several years of solving this issue, yet you waited until
> just before freeze

No, me and Luis Uribe just recently found interest in it, and thought
it'd be
great to have it in Wheezy too.

> and the option you came up with was to kick a
> maintainer.
>

We aren't kicking him, we want to have the package team maintained.
He's fine to come and join!

> Did you consider an NMU?
>

Yes, but the issue is that there's lots of invasive changes that we would
like to make to the packaging. Having a look to the current state of the
package, it'd be nearly totally re-written. There's not a single line in the
debian/control file that satisfies me, I'd like to move from dh_php_make
to pkg-php-tools (that implies, from CDBS to dh 8 sequencer), etc.

This doesn't really qualify for an NMU, nor does the upgrade to the latest
upstream version.

On 05/30/2012 07:45 AM, Charles Plessy wrote:
> I concur. It is socially and technically safer to give about two week-ends to
> answer, keeping time zones in mind.

My reasoning over the one week only was that the package hasn't been
maintained since 2008, so that anyways, it feels like the package isn't
well enough maintained to be left to Jack sole responsibility. Again, he
would be free to join the PKG PEAR team. But I'll wait one more week
as you suggest then, this doesn't mater much...

> If after this delay you have no news, my
> opinion is that hijacking is the best solution. The maintainer's other
> packages have already attracted three NMUs in total, and I have not seen a bug
> report with his answer after 2009 (although got some packages sponsored in
> 2011). By the way, perhaps you can keep his sponosor (rmgolbeck) in the loop,
> maybe he knows other ways to contact the maintainer ?
>
rmgolbeck is Cc: to this mail.

Cheers,

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FC59455.9060507@goirand.fr">http://lists.debian.org/4FC59455.9060507@goirand.fr
 
Old 05-30-2012, 09:11 AM
Jonas Smedegaard
 
Default Orphaning php-codesniffer, then take it over by the PHP PEAR team

On 12-05-30 at 11:30am, Thomas Goirand wrote:
> We aren't kicking him, we want to have the package team maintained.
> He's fine to come and join!

You want to play by your rules (file), not his. That's kicking to me.


> This doesn't really qualify for an NMU, nor does the upgrade to the
> latest upstream version.

*nothing* qualifies for a hijacking.

With hijacking I mean disrespectful takeover.

Either respect maintainership by only NMUing, or respectfully resolve
with the Debian community that the current maintainer is unfit for the
task. You do the latter but instead of the normal use of MIA tracking
you use Debian freeze as argument for swift takeover. I find it not
respectful to rush processing like that!


I am not at all surprised that this is yet another sponsored package
bit-rotting. Personally I never liked how we allow maintainer to be
someone not in Debian: There is too great a risk of drive-by
contributions :-(

...but we should not improve quality of packages by relaxing the respect
of the maintainer. We should hold maintainers responsible to their
actions - and that is only really possible to do with "social pride"
which is lacking when maintainer is outside of Debian.


- Jonas

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

[x] quote me freely [ ] ask before reusing [ ] keep private
 
Old 05-30-2012, 01:41 PM
Thomas Goirand
 
Default Orphaning php-codesniffer, then take it over by the PHP PEAR team

On 05/30/2012 05:11 PM, Jonas Smedegaard wrote:
> *nothing* qualifies for a hijacking.
>
> With hijacking I mean disrespectful takeover.
>
> Either respect maintainership by only NMUing, or respectfully resolve
> with the Debian community that the current maintainer is unfit for the
> task.

Ok, I will NMU then. Thanks for voicing your opinion, which was exactly
why I asked.

> 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. That's also 2 release ago if
I'm not mistaking, which is why I talked about release names. That's a long
time, IMO, and thought it could be a reason good enough to have the package
go into the team. Also, I did *not* want to hijack the package, but that it
becomes orphaned, because left unmaintained, and asked for opinions of
others if this was the way to go.

Now, seeing your arguments, I agree with it (especially the part where we
should put maintainers in front of their duty). 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.

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?

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FC6238A.4070500@debian.org">http://lists.debian.org/4FC6238A.4070500@debian.org
 
Old 05-30-2012, 02:19 PM
Gergely Nagy
 
Default Orphaning php-codesniffer, then take it over by the PHP PEAR team

Thomas Goirand <zigo@debian.org> writes:

> 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?

Since the package has been unmaintained for years, and from what I've
read so far, it does seem that it will end up under a team's umbrella
anyway in a month's time, I wouldn't care about any possibly hurt
feelings, and update the packaging to current practice.

Quality and maintainability should come before the letter of any NMU
recommendations and best practices.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 878vg9eopq.fsf@algernon.balabit">http://lists.debian.org/878vg9eopq.fsf@algernon.balabit
 
Old 05-30-2012, 04:14 PM
Jon Dowland
 
Default Orphaning php-codesniffer, then take it over by the PHP PEAR team

On Wed, May 30, 2012 at 08:45:22AM +0900, Charles Plessy wrote:
> I concur. It is socially and technically safer to give about two week-ends to
> answer, keeping time zones in mind.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599617 was filed in 2010, no
answer, ping in 2011, no answer. So it depends on when you consider the clock
starting.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120530161413.GA23744@debian">http://lists.debian.org/20120530161413.GA23744@debian
 
Old 05-30-2012, 04:35 PM
Arno Töll
 
Default Orphaning php-codesniffer, then take it over by the PHP PEAR team

Hi,

On 30.05.2012 18:17, Bart Martens wrote:
> On Wed, May 30, 2012 at 09:41:30PM +0800, Thomas Goirand wrote:
>> 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?
>
> It's difficult to answer that without seeing the NMU package. It's not so
> black and white, in my opinion. Generally I think it is best to keep the
> changes minimal, but I see no harm in fixing a few real problems that are not
> part of packaging the newest upstream release.

why such a hurry? I thought the purpose would be to ship an up to date
version of php-codesniffer in Wheezy? The user does not care if that's
coming from a 1.0 source package using quilt or whatever fancy
alternative tools we have available to date. Hence, please, keep the
changes as minimally invasive as possible and follow the usual rules for
a NMU as much as possible.

The non essential cosmetic changes can still be done after having
php-codesniffer in an up to date version in Wheezy and Thomas waited a
sensible amount of time for feedback by the current maintainer.

I'm not saying this package shouldn't deserve more packaging love, but
this does not need to happen *now* beyond the bare essential minimum to
improve the user experience in Wheezy.


--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
 
Old 05-30-2012, 05:55 PM
Jonas Smedegaard
 
Default Orphaning php-codesniffer, then take it over by the PHP PEAR team

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
 

Thread Tools




All times are GMT. The time now is 01:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org