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.
&
Re: why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Saturday 02 June 2012 05:36:04 Thomas Goirand wrote: > On 06/02/2012 04:43 AM, Holger Levsen wrote: > > now that I notice the subject change I also notice the original > > subject... > > > > hi Thomas 8-) > > LOL ! > > I'm amazed that it's seems I'm capable of creating huge uncontrollable > threads out of nowhere (eg: this isn't the first time). No one is perfect, but in this paticular case, I think your good will, patience, complete lack of hostality and desire to communicate the whole issue, has become a victim of what I'd more or less qualify as an unlawful or inappropriate interference. So, thank you for your commitment, and for being that patient and endurant! > I swear its never intended ! :) OMG, I hope we don't need any oath-taking ceremonies any time we try to improve something within Debian. -- pub 4096R/0E4BD0AB -- 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/201206021046.50162.danc...@spnet.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 11:05am, Jonas Smedegaard wrote: > Thanks to Daniel Kahn Gilmore for lending me the bike! Gillmor. Sorry! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 06/02/2012 04:43 AM, Holger Levsen wrote: > now that I notice the subject change I also notice the original subject... > > hi Thomas 8-) > LOL ! I'm amazed that it's seems I'm capable of creating huge uncontrollable threads out of nowhere (eg: this isn't the first time). I swear its never intended ! :) Thomas -- 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/4fc98a24.3020...@debian.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 01.06.2012 21:49, Tollef Fog Heen wrote: > ]] Jonas Smedegaard > > Hiya, > >> I am genuinely interested in understanding the reasons for labeling >> sponsoree rather than sponsor as maintainer. Could you (or anyone) >> elaborate on that? > > If I'm sponsoring a package, it means I've checked that its quality is > good enough that I consider it a worthwhile addition to Debian. I'm not > doing the actual maintenance, I'm reviewing parts of the maintenance > being done, and so giving me the maintainership would be wrong. There's > both the «who should you talk to about this package» as well as > crediting the person who's doing the actual legwork. Nod. This is basically the same I do when sponsoring a package. I carefully review the package before the upload and that's about it. I don't keep track of bugs that are filed against this package nor do I start maintaining it / feel responsible for it. If my upload fucked up other packages or created a mess in an ongoing transition, then of course I would feel responsible sorting this out together with the maintainer. But in the usual case a sponsored upload is a one-time thing ( I do have regular sponsoree's though) Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Friday 01 June 2012 20:08:22 Jonas Smedegaard wrote: > On 12-06-01 at 06:06pm, George Danchev wrote: > > On Thursday 31 May 2012 16:54:13 Scott Kitterman wrote: > > > > Hi, Hi, > > > > ...hence the Sponsors (who are also a full-fledged DDs) are > > > > responsible. It is that simple. > > > > > > If it's really that simple, one should never sponsor a package one > > > doesn't care to maintain. If this is the case, we should just do > > > away with sponsorship and require the uploader to be either > > > Maintainer or in Uploaders unless it's an NMU (note: I don't think > > > this is what we want). > > > > I don't think this is that black and white indeed. In the case of > > unresponsive non-DD maintainer, obviously the Sponsors (having more > > powerful pedals and knobs than the sponsoree wrt to the archive) have > > several courses of action (in no particular order; various > > combinations are also possible): > > > > * step in and maintain the package themselves > > * ask for help, search for co-maintainers, etc > > * suggest orphanage > > * you name it > > > > and I guess this is a very basic, but fairly sufficient measure to > > handle the the case of run-away non-DD maintainers. > > Sorry if I am dense, but those pedals and knobs look like maintenance > ones to me: Maintaining a package via long series of non-invasive NMUs does not declare maintainership (I meant pedals as in sponsors are able to upload without their sponsoree). It is just inconvenient for both the maintainers and the end users, and should be a temporal measure in the ideal case (and yes, I know we have packages in the archive effectively maintained via NMUs for many years). > Simply relabel the sponsor as maintainer as Scott > (non-)proposes and it _is_ black and white to me. > > I am genuinely interested in understanding the reasons for labeling > sponsoree rather than sponsor as maintainer. Could you (or anyone) > elaborate on that? Maintainer field is meaningless, it is very meaningful. Why not just think of it this way (hopefully this could make you sleep better :) - If a Maintainer field points to a non-DD entity and that entity disappears from the horizon, then a DD-entity (the Sponsor [1], the Safeguard if you want) should do something meaningful to help to resolve the situation. This is not to say that the DD-entity (the Sponsor) is then allowed to perform hostile acts and all sorts of unlawful interferences (e.g. a hijacks) in the terms of the Debian normative docs. [1] http://udd.debian.org/sponsorstats.cgi -- pub 4096R/0E4BD0AB -- 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/201206012309.57302.danc...@spnet.net
Re: why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
now that I notice the subject change I also notice the original subject... hi Thomas 8-) -- 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/201206012243.38011.hol...@layer-acht.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thu, May 31, 2012 at 06:15:47PM +0200, Bernd Zeimetz wrote: > Especially do I fail to understand why a member of the TC, who took part > in such discussions before > (https://lists.debian.org/debian-devel/2006/05/msg00457.html to name an > example), and encouraged people to do so (that is how I understand the > mentioned mail), So to be clear, no, I was not endorsing a hijacking of that package. My mail there was a response to an ill-considered defense of the current bacula maintainer at that time. I think I'm allowed to believe both that a package is not well-maintained, and that developers shouldn't take matters into their own hands to resolve such problems. The bacula package *was* in bad shape at that time, and something needed to be done. That doesn't mean the particular "something" that was done - starting a painful flamewar on debian-devel that led to the previous maintainer deciding to walk away from the package (i.e., voluntarily orphaning it after being demotivated) was the right thing to do. However, since the maintainer did walk away voluntarily, the TC didn't really have grounds to intervene... and probably wouldn't have sided with him anyway, so probably wouldn't have been less painful. Many of the earlier "hijack" mails on debian-devel also followed a very different process than the one described in the present thread (e.g., allowing an indeterminate amount of "time", resulting in the original maintainer resuming maintenance of the package - https://lists.debian.org/debian-doc/2006/09/msg00071.html); or resulted in amicable resolutions, with the previous maintainer explicitly approving the hijacking (https://lists.debian.org/debian-devel/2001/05/msg00183.html); or were intercepted by someone in the know, who diverted the hijack to an NMU (https://lists.debian.org/debian-devel/2006/07/msg00568.html). Unfortunately, it seems this has served as precedent, and the message people have taken away is that it's perfectly ok to hijack packages... when almost none of the "hijacking" statements have ever resulted in anything of the sort. > is now on a killing spree. All he is doing is to encourage people to give > up their idea to improve Debian. From hijacks to killing sprees... yes, I definitely think there's a language barrier of some kind here. ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Fri, Jun 1, 2012 at 4:22 PM, Holger Levsen wrote: > Hi, > > On Freitag, 1. Juni 2012, Steve Langasek wrote: > [...] >> 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. I kinda like "Package reappropriation" myself :) > > thanks for explaining, makes completly sense to me now! :-) > > (And I do think it's partly a language issue. For non-native speakers "hijack" > is probably a bit more romantic and less obviously evil 8-) > > > cheers, > Holger > > (And for those poor people (should they exist...) just reading my mail and not > Steve's and thus having no idea what is ment with "salvaging a package": go > read Steve's mail.) > > > -- > 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/20120601.16740.hol...@layer-acht.org > -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq -- 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/CAO6P2QS07EHUODXJ=RdudQDzqBz88=DvhA1ad=7xzwdmcbf...@mail.gmail.com
why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi, On Freitag, 1. Juni 2012, Steve Langasek wrote: [...] > 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. thanks for explaining, makes completly sense to me now! :-) (And I do think it's partly a language issue. For non-native speakers "hijack" is probably a bit more romantic and less obviously evil 8-) cheers, Holger (And for those poor people (should they exist...) just reading my mail and not Steve's and thus having no idea what is ment with "salvaging a package": go read Steve's mail.) -- 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/20120601.16740.hol...@layer-acht.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
]] Jonas Smedegaard Hiya, > I am genuinely interested in understanding the reasons for labeling > sponsoree rather than sponsor as maintainer. Could you (or anyone) > elaborate on that? If I'm sponsoring a package, it means I've checked that its quality is good enough that I consider it a worthwhile addition to Debian. I'm not doing the actual maintenance, I'm reviewing parts of the maintenance being done, and so giving me the maintainership would be wrong. There's both the «who should you talk to about this package» as well as crediting the person who's doing the actual legwork. (I'm talking about what I do here, I'm not saying this is the one and only way to do sponsorship.) Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/878vg6olrq@xoog.err.no
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
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.
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.
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.
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.
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 hij
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-06-01 at 06:06pm, George Danchev wrote: > On Thursday 31 May 2012 16:54:13 Scott Kitterman wrote: > > Hi, > > > > ...hence the Sponsors (who are also a full-fledged DDs) are > > > responsible. It is that simple. > > > > If it's really that simple, one should never sponsor a package one > > doesn't care to maintain. If this is the case, we should just do > > away with sponsorship and require the uploader to be either > > Maintainer or in Uploaders unless it's an NMU (note: I don't think > > this is what we want). > > I don't think this is that black and white indeed. In the case of > unresponsive non-DD maintainer, obviously the Sponsors (having more > powerful pedals and knobs than the sponsoree wrt to the archive) have > several courses of action (in no particular order; various > combinations are also possible): > > * step in and maintain the package themselves > * ask for help, search for co-maintainers, etc > * suggest orphanage > * you name it > > and I guess this is a very basic, but fairly sufficient measure to > handle the the case of run-away non-DD maintainers. Sorry if I am dense, but those pedals and knobs look like maintenance ones to me: Simply relabel the sponsor as maintainer as Scott (non-)proposes and it _is_ black and white to me. I am genuinely interested in understanding the reasons for labeling sponsoree rather than sponsor as maintainer. Could you (or anyone) elaborate on that? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thursday 31 May 2012 16:54:13 Scott Kitterman wrote: Hi, > > ...hence the Sponsors (who are also a full-fledged DDs) are responsible. > > It is that simple. > > If it's really that simple, one should never sponsor a package one doesn't > care to maintain. If this is the case, we should just do away with > sponsorship and require the uploader to be either Maintainer or in > Uploaders unless it's an NMU (note: I don't think this is what we want). I don't think this is that black and white indeed. In the case of unresponsive non-DD maintainer, obviously the Sponsors (having more powerful pedals and knobs than the sponsoree wrt to the archive) have several courses of action (in no particular order; various combinations are also possible): * step in and maintain the package themselves * ask for help, search for co-maintainers, etc * suggest orphanage * you name it and I guess this is a very basic, but fairly sufficient measure to handle the the case of run-away non-DD maintainers. -- pub 4096R/0E4BD0AB -- 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/201206011806.53799.danc...@spnet.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Le Fri, Jun 01, 2012 at 01:47:07AM +0200, Salvo Tomaselli a écrit : > > Jonas, I think we all agree that the Maintainer should Maintain > > whatever he signed up to. Non-Debian people have the right to maintain > > packages through a sponsor, and they are encouraged to. And they are > > encouraged to look for a different sponsor if their current one stops > > being responsive, and all that. > > > > However, we cannot expect them to remain active and interested > > forever. > But you can safely assume that a DD will remain interested in debian forever? > Aren't DD common human beings after all? (seems somebody would disagree) Hi all, Raphaël has interesting propositions somewhat related to matter in DEP-2. http://dep.debian.net/deps/dep2/ In particular, I think that we would benefit of a way to better describe the maintainer's involvement and expectations, as it would help to chose the best action to take when he does not give signs of activity in Debian for a long time and becomes unreachable without having managed to drop a message about this (which I think is an important thing to do when possible). http://dep.debian.net/deps/dep2/ There was some discussion about this DEP in january on debian-qa@l.d.o. I do not remember if it was discussed there, but I think that having expiration dates to the statements (like “I packaged it because I use it daily”) would help keeping the information accurate. http://lists.debian.org/debian-qa/2012/01/threads.html#00070 Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/2012060116.ga6...@falafel.plessy.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
> Jonas, I think we all agree that the Maintainer should Maintain > whatever he signed up to. Non-Debian people have the right to maintain > packages through a sponsor, and they are encouraged to. And they are > encouraged to look for a different sponsor if their current one stops > being responsive, and all that. > > However, we cannot expect them to remain active and interested > forever. But you can safely assume that a DD will remain interested in debian forever? Aren't DD common human beings after all? (seems somebody would disagree) -- Salvo Tomaselli -- 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/201206010147.07638.tipos...@tiscali.it
On "hijacking" (was: Orphaning php-codesniffer, then take it over by the PHP PEAR team)
On Wed, 30 May 2012 18:03:05 -0700, Steve Langasek wrote: > There is no excuse for hijacking a package, ever. [...] Hi Steve, while I really appreciate both your technical work and expertise as well as your personal care for Debian, this mail didn't go down well with me, for two reasons: - It sounds unnecessarily aggressive to me with threats and recourse to positions (TC), statements ex cathedra (e.g. "by definition"), and killer phrases (e.g. "empty words"); - regarding the contents, IMO you're painting the issue a bit too black-or-white; I think there's neither a common understanding what "hijacking" actually means nor a one-answer-fits-all-situations answer on this issue. I'd like to kindly ask you to join a common endeavour to come closer to a better handling of the recurring tensions between strong maintainership on the one hand and improving our distribution on the other hand. Cheers, gregor, just wanting to give a feedback -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: The Beatles: Sun King signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi Thomas, On Thu, May 31, 2012 at 02:01:51PM +0800, Thomas Goirand wrote: > On 05/31/2012 09:03 AM, Steve Langasek wrote: > > 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. > Why are people talking about urgency and hijack? None applies to this > package. > Please refer to the title of this thread, where I wrote: > Orphaning *THEN* take over > Is there anything wrong with that? Your original mail also said: > 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. "2 or 3 days" *does* imply urgency, and this is the part of your original proposal that I object to. The rest of my objections are directed not at you, but at those who are attempting to legitimize "hijacking" in this thread. > In fact, it's the total opposite way, I asked others if they found it ok to > ask for the package to be orphaned after only a week, because I thought that > 4 years without a refresh of the package, multiple NMUs of other packages > from the same maintainer, was enough to shorten the "ping period". I also > wrote about my intention to get the original maintainer in the team if he > wishes so. Then considering Jonas opinion, I agreed to leave one week more, > even if I know that the orphaning process may take some time as well. > Is this hijack? Is this rushing? I don't think it's a hijack. I do think it's rushing. I recognize that there's a cost to having to set a mental alarm for tracking issues like this, but if we haven't already made a determination that the maintainer is MIA, then it takes some time to do this appropriately. We shouldn't simply assume that NMUs and unanswered low-priority bugs mean the package is up for grabs - particularly as we *want* NMUs, we don't want maintainers to feel they need to do no-changes reuploads just to confirm NMUs, and we don't want maintainers to have their packages taken away from them as a result of them doing the right thing wrt NMUs. On Fri, Jun 01, 2012 at 02:29:29AM +0800, Thomas Goirand wrote: > On 05/31/2012 10:52 PM, Mehdi Dogguy wrote: > > Please note that "badly maintained" is something quite different from > > "not maintained". AFAICS, the package we are talking about is not > > affected by severe or critical bugs. > That's a mater of views. #470294 should be made RC IMO. > Or is writing to /usr not a good candidate for an RC bug? > I thought this was a "serious violation of the policy". Am I wrong? I think marking this 'serious' is appropriate, but given that it *wasn't* marked 'serious' until today, this also does not justify an expedited orphaning. It's not reasonable to claim the maintainer was failing to act on a RC bug when no one had bothered to inform the maintainer (who is not a DD, and therefore may not have understood) that it was an RC bug. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
severity 470294 serious thanks Hi, On Donnerstag, 31. Mai 2012, Thomas Goirand wrote: > That's a mater of views. #470294 should be made RC IMO. "somebody should do something" ;-) > Or is writing to /usr not a good candidate for an RC bug? > I thought this was a "serious violation of the policy". Am I wrong? No, that's a serious issue indeed. cheers, Holger, who is a happy+frequent BTS _user_ :-D -- 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/201205312038.03029.hol...@layer-acht.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 10:52 PM, Mehdi Dogguy wrote: > Please note that "badly maintained" is something quite different from > "not maintained". AFAICS, the package we are talking about is not > affected by severe or critical bugs. That's a mater of views. #470294 should be made RC IMO. Or is writing to /usr not a good candidate for an RC bug? I thought this was a "serious violation of the policy". Am I wrong? Cheers, Thomas -- 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/4fc7b889.3000...@debian.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 04:52 PM, Mehdi Dogguy wrote: > On 31/05/12 16:40, Thomas Goirand wrote: >> 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. >> > > Please note that "badly maintained" is something quite different from > "not maintained". AFAICS, the package we are talking about is not > affected by severe or critical bugs. The number of bugs says nothing about a package being maintained or not. Maybe just nobody uses it anymore because it is too old? 'Please package the current upstream version'-bugs are wishlist only, unfortunately. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fc7a889.1090...@bzed.de
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 06:25 PM, Mehdi Dogguy wrote: > On 31/05/12 18:15, Bernd Zeimetz wrote: >> >> Part of the common and established procedure is to mail d-devel if >> you intend to hijack a package > > True, but it is _not_ common (nor acceptable) to let only 2-3 days for > the maintainer to reply. They waited 5 days and want to wait 2-3 more days. That makes 8 days, a short time but waiting a bt longer would be easy, I guess. > The rest of the thread raised other questions such as the responsibility > of a sponsor, but it seems OT wrt. the original request. > > Regards, > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fc7a23f.7000...@bzed.de
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Jonas Smedegaard dijo [Thu, May 31, 2012 at 05:52:47PM +0200]: > > > You avoided my question, it seems: What does "Maintainer:" mean, then? > > > > What does "Uploaders:" field mean? > > You still avoid my question: What does "Maintainer:" mean? This is getting silly. Please stop the word-definitions game. Jonas, I think we all agree that the Maintainer should Maintain whatever he signed up to. Non-Debian people have the right to maintain packages through a sponsor, and they are encouraged to. And they are encouraged to look for a different sponsor if their current one stops being responsive, and all that. However, we cannot expect them to remain active and interested forever. I can expect you (as a person I've known for many years already) to remain active and look after your packages. But we cannot expect the same from a person not involved in Debian any further than in having maintained a couple of packages for a couple of months. Taking over a package from you should be quite a different thing than taking it over from a person not involved in the project. -- 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/20120531163116.ga21...@gwolf.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 31/05/12 18:15, Bernd Zeimetz wrote: Part of the common and established procedure is to mail d-devel if you intend to hijack a package True, but it is _not_ common (nor acceptable) to let only 2-3 days for the maintainer to reply. The rest of the thread raised other questions such as the responsibility of a sponsor, but it seems OT wrt. the original request. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- 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/4fc79b62.2000...@dogguy.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 04:57 PM, Mehdi Dogguy wrote: > On 31/05/12 15:11, Bernd Zeimetz wrote: >> On 05/31/2012 03:03 AM, Steve Langasek wrote: >>> [...] >> >>> 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. >> >> So asking people who want to work actively on a package to wait for >> months or years because it is not compltely clear if the original >> maintainer is MIA or not, or just nobody had the time to look at the >> MIA status, is social? It does not help Debian at all. >> >>> 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. >> >>> From a member of the TC I would expect some useful input on how to >>> fix >> an obviously broken (since years!) process instead of trying to >> forcibly trying to choke down people who actively want to improve >> Debian. Welcome to the dictatorship of the TC. >> > > I think what Steve wanted to say is that we have procedures for theses > situations and we should follow those procedures because they exist and > we have concensus. The procedures in question might not be perfect or > completely disfunctional but that is another topic. > > You may very well try to change these procedures and discuss new rules > or the needed changes to apply on -devel, but you should not ignore them > and force your own (which was, aiui, what the original submitter of this > thread wanted to do) just because $foo. Part of the common and established procedure is to mail d-devel if you intend to hijack a package. Please have a look into the archives of this mailinglist, searching for intend to hijack debian-devel@lists.debian.org site:lists.debian.org gives a lot of results, including some dating back to 2006. If I remember right this includes at least one or two messages from me, which did not receive negative replies at all. So I completely fail why the original submitter's mail is *that* bad (your $foo in this case being the maintainer MIA for 3 years), and I also fail to understand why it needs a major flamewar. It is common practise for years to discuss hijacks in such cases (original maintainer MIA for years, or even worse, maintainer lacking the necessarz skill to maintain important packages) on this list and hijack them if there is consensus about doing so. Especially do I fail to understand why a member of the TC, who took part in such discussions before (https://lists.debian.org/debian-devel/2006/05/msg00457.html to name an example), and encouraged people to do so (that is how I understand the mentioned mail), is now on a killing spree. All he is doing is to encourage people to give up their idea to improve Debian. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fc79933.7080...@bzed.de
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi Thomas, On Donnerstag, 31. Mai 2012, Thomas Goirand wrote: > 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. yes, please do that. Ask the MIA team to orphan it and then adopt it. That would be awesome. cheer, Holger -- 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/201205311810.47816.hol...@layer-acht.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Donnerstag, 31. Mai 2012, Jonas Smedegaard wrote: > You still avoid my question: What does "Maintainer:" mean? why do you ask rhetoric questions? It's defined in policy and you know it. So whats the point? -- 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/201205311808.55306.hol...@layer-acht.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 04:43pm, George Danchev wrote: > On Thursday 31 May 2012 16:15:31 Jonas Smedegaard wrote: > > [dropping PHP Pear team as cc] > > > > On 12-05-31 at 03:16pm, George Danchev wrote: > > > On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: > > > > > You and a lot of others fail to realize that the *SPONSOR* is > > > > > responsible for the package. > > > > > > > > Huh?!? > > > > > > > > What does "Maintainer:" mean if not the entity being responsible > > > > for, well, maintaining?!? > > > > > > Who is responsible for the package maintenance in the case where a > > > non-DD is listed in "Maintainer:", and the package is obviosuly signed > > > and uploaded (effectively sponsored) by a DD? I guess it is perfectly > > > reasonable to expect that DD, being in the role of sponsor, is > > > responsible for the package quality and further maintenance. Sponsors > > > are full-fledged DDs, and trying to claim that they are not > > > responsible, or are somehow less responsible than any other > > > non-sponsoring DDs, for the uploads they have done, is obviously plain > > > wrong. > > > > You avoided my question, it seems: What does "Maintainer:" mean, then? > > What does "Uploaders:" field mean? You still avoid my question: What does "Maintainer:" mean? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 31/05/12 15:11, Bernd Zeimetz wrote: On 05/31/2012 03:03 AM, Steve Langasek wrote: [...] 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. So asking people who want to work actively on a package to wait for months or years because it is not compltely clear if the original maintainer is MIA or not, or just nobody had the time to look at the MIA status, is social? It does not help Debian at all. 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. From a member of the TC I would expect some useful input on how to fix an obviously broken (since years!) process instead of trying to forcibly trying to choke down people who actively want to improve Debian. Welcome to the dictatorship of the TC. I think what Steve wanted to say is that we have procedures for theses situations and we should follow those procedures because they exist and we have concensus. The procedures in question might not be perfect or completely disfunctional but that is another topic. You may very well try to change these procedures and discuss new rules or the needed changes to apply on -devel, but you should not ignore them and force your own (which was, aiui, what the original submitter of this thread wanted to do) just because $foo. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- 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/4fc786e9.6020...@dogguy.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thursday, May 31, 2012 03:16:06 PM George Danchev wrote: > On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: > > Hi, > > > > You and a lot of others fail to realize that the *SPONSOR* is > > > responsible for the package. > > > > Huh?!? > > > > What does "Maintainer:" mean if not the entity being responsible for, > > well, maintaining?!? > > Who is responsible for the package maintenance in the case where a non-DD is > listed in "Maintainer:", and the package is obviosuly signed and uploaded > (effectively sponsored) by a DD? I guess it is perfectly reasonable to > expect that DD, being in the role of sponsor, is responsible for the > package quality and further maintenance. Sponsors are full-fledged DDs, and > trying to claim that they are not responsible, or are somehow less > responsible than any other non-sponsoring DDs, for the uploads they have > done, is obviously plain wrong. > > > If the maintainer fails to keep the package in a useful shape it is > > > the sponsor's responsibility to do so. And last but not least it > > > should be the sponsor's decision to orphan a package if the maintainer > > > is MIA or not doing his job properly. It is also the sponsors > > > responsibility to try to figure out if a maintainer is willing to do > > > his job longer than one upload before sponsoring a package at all. > > > > I have heard before the argument of the sponsor having responsibility, > > but in reality I have *never* heard of sponsors actually being held > > responsible for anything but the concrete upload of a specific packaging > > release. > > > > ...which leads to my concern for high risk of drive-by contributions! > > ...hence the Sponsors (who are also a full-fledged DDs) are responsible. It > is that simple. If it's really that simple, one should never sponsor a package one doesn't care to maintain. If this is the case, we should just do away with sponsorship and require the uploader to be either Maintainer or in Uploaders unless it's an NMU (note: I don't think this is what we want). Scott K -- 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/1888095.EXhfyjLExP@scott-latitude-e6320
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 31/05/12 16:40, Thomas Goirand wrote: 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. Please note that "badly maintained" is something quite different from "not maintained". AFAICS, the package we are talking about is not affected by severe or critical bugs. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- 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/4fc785ae.40...@dogguy.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thursday 31 May 2012 16:15:31 Jonas Smedegaard wrote: > [dropping PHP Pear team as cc] > > On 12-05-31 at 03:16pm, George Danchev wrote: > > On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: > > > > You and a lot of others fail to realize that the *SPONSOR* is > > > > responsible for the package. > > > > > > Huh?!? > > > > > > What does "Maintainer:" mean if not the entity being responsible > > > for, well, maintaining?!? > > > > Who is responsible for the package maintenance in the case where a > > non-DD is listed in "Maintainer:", and the package is obviosuly signed > > and uploaded (effectively sponsored) by a DD? I guess it is perfectly > > reasonable to expect that DD, being in the role of sponsor, is > > responsible for the package quality and further maintenance. Sponsors > > are full-fledged DDs, and trying to claim that they are not > > responsible, or are somehow less responsible than any other > > non-sponsoring DDs, for the uploads they have done, is obviously plain > > wrong. > > You avoided my question, it seems: What does "Maintainer:" mean, then? What does "Uploaders:" field mean? > Seems to me that for sponsored packages the Maintainer field is a joke! The gpg signature applied to the upload is not a joke, at all. > Seems to me that for sponsored packages we need access to ftp logfiles > to resolve who is responsible for maintaining the package. Then, please, allow me to introduce you to the 'who-uploads' utility. > I find both of those plain wrong. Possibly obviously and maybe even > hilariously simple, but wrong nonetheless. Nothing is wrong with the control fields and the gpg signatures applied to the uploads actually. -- pub 4096R/0E4BD0AB -- 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/201205311643.08151.danc...@spnet.net
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: http://qa.debian.org/developer.php?login=pkg-php-p...@lists.alioth.debian.org 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... Thomas -- 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/4fc782eb.2090...@debian.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thursday 31 May 2012 14:43:00 Jonas Smedegaard wrote: > On 12-05-31 at 08:02pm, Thomas Goirand wrote: > > On 05/31/2012 04:36 PM, Jonas Smedegaard wrote: > > > Hijacking, in my vocabulary, is when a non-maintainer takes matters > > > in his/her/their own hands and takes over maintainership without the > > > consent of the former maintainer and outside formal Debian > > > procedures. > > > > Nobody did that, or had the intention to do this here. > > > > I already asked you privately: please stop spreading wrong information > > about my intentions. This begins to be really annoying. > > 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? > > 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? Or you should better understand that "maintainer is always there to provide consent" is also a blatant assumption, and that some sort of fault-tolerance is actually needed in the real life, at least in my parallel reality. Sometimes it is impossible to reach the maintainer for a very long period of time, due to several even prosaic reasons, hence something or someone should be able to unblock the hard blockage in a reasonable amount of time. Maintaining the package in between for a very long amount of time (like years), by very long series of minimal, non-invasive NMUs, which would also imply no new upstream versions or newly created packaging tools, seems quite suboptimal to me. Thus orphan + adopt is perfectly in order. -- pub 4096R/0E4BD0AB -- 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/201205311635.33008.danc...@spnet.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
[dropping PHP Pear team as cc] On 12-05-31 at 03:16pm, George Danchev wrote: > On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: > > > You and a lot of others fail to realize that the *SPONSOR* is > > > responsible for the package. > > > > Huh?!? > > > > What does "Maintainer:" mean if not the entity being responsible > > for, well, maintaining?!? > > Who is responsible for the package maintenance in the case where a > non-DD is listed in "Maintainer:", and the package is obviosuly signed > and uploaded (effectively sponsored) by a DD? I guess it is perfectly > reasonable to expect that DD, being in the role of sponsor, is > responsible for the package quality and further maintenance. Sponsors > are full-fledged DDs, and trying to claim that they are not > responsible, or are somehow less responsible than any other > non-sponsoring DDs, for the uploads they have done, is obviously plain > wrong. You avoided my question, it seems: What does "Maintainer:" mean, then? Seems to me that for sponsored packages the Maintainer field is a joke! Seems to me that for sponsored packages we need access to ftp logfiles to resolve who is responsible for maintaining the package. I find both of those plain wrong. Possibly obviously and maybe even hilariously simple, but wrong nonetheless. - Jonas Who appreciate non-DM contributions, just not common hinting of them -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: Hi, > > You and a lot of others fail to realize that the *SPONSOR* is > > responsible for the package. > > Huh?!? > > What does "Maintainer:" mean if not the entity being responsible for, > well, maintaining?!? Who is responsible for the package maintenance in the case where a non-DD is listed in "Maintainer:", and the package is obviosuly signed and uploaded (effectively sponsored) by a DD? I guess it is perfectly reasonable to expect that DD, being in the role of sponsor, is responsible for the package quality and further maintenance. Sponsors are full-fledged DDs, and trying to claim that they are not responsible, or are somehow less responsible than any other non-sponsoring DDs, for the uploads they have done, is obviously plain wrong. > > If the maintainer fails to keep the package in a useful shape it is > > the sponsor's responsibility to do so. And last but not least it > > should be the sponsor's decision to orphan a package if the maintainer > > is MIA or not doing his job properly. It is also the sponsors > > responsibility to try to figure out if a maintainer is willing to do > > his job longer than one upload before sponsoring a package at all. > > I have heard before the argument of the sponsor having responsibility, > but in reality I have *never* heard of sponsors actually being held > responsible for anything but the concrete upload of a specific packaging > release. > > ...which leads to my concern for high risk of drive-by contributions! ...hence the Sponsors (who are also a full-fledged DDs) are responsible. It is that simple. -- pub 4096R/0E4BD0AB -- 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/201205311516.06495.danc...@spnet.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 03:03 AM, Steve Langasek wrote: >[...] > 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. So asking people who want to work actively on a package to wait for months or years because it is not compltely clear if the original maintainer is MIA or not, or just nobody had the time to look at the MIA status, is social? It does not help Debian at all. > 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. >From a member of the TC I would expect some useful input on how to fix an obviously broken (since years!) process instead of trying to forcibly trying to choke down people who actively want to improve Debian. Welcome to the dictatorship of the TC. > [...] -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fc76df2.7010...@bzed.de
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 08:02pm, Thomas Goirand wrote: > On 05/31/2012 04:36 PM, Jonas Smedegaard wrote: > > Hijacking, in my vocabulary, is when a non-maintainer takes matters > > in his/her/their own hands and takes over maintainership without the > > consent of the former maintainer and outside formal Debian > > procedures. > > > Nobody did that, or had the intention to do this here. > > I already asked you privately: please stop spreading wrong information > about my intentions. This begins to be really annoying. 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? 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? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
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
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 04:36 PM, Jonas Smedegaard wrote: > Hijacking, in my vocabulary, is when a non-maintainer takes matters in > his/her/their own hands and takes over maintainership without the > consent of the former maintainer and outside formal Debian procedures. > Nobody did that, or had the intention to do this here. I already asked you privately: please stop spreading wrong information about my intentions. This begins to be really annoying. Thomas -- 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/4fc75dcf.8060...@debian.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Donnerstag, 31. Mai 2012, Cyril Brulebois wrote: > [ Holger, that's fingerpointing. Pointing to how you quickly dealt with > those packages, thanks again. :-) ] /me happily fingerpoints back at the release team and esp. KiBi, who greatly deal with trying to get 1 packages and 1000 people in sync. Thanks a huge lot for all your work! :-) -- 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/201205311213.46790.hol...@layer-acht.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi Enrico, On 12-05-31 at 09:19am, Enrico Zini wrote: > On Thu, May 31, 2012 at 02:01:51PM +0800, Thomas Goirand wrote: > > > Did you see me writing "I'd like to hijack php-codesniffer in order > > to rush and get it into wheezy in time before the freeze"? *NO* ! I > > didn't write that. > > Agreed. I'd have expected people, if anything, to answer suggesting > the correct procedure to get things done in this case. I was surprised > to see replies harshly escalating matters this way. > > My understanding is that we have a package that looks unmaintained for > 4 years. Yelling at those who volunteer to do some work on it, instead > of guiding them to do it in the best way, seems silly and rather > un-debianish to me. Rephrasing orphaning without maintainer consent + takeover as hijacking is yelling? Suggesting to do an NMU instead of hijacking is un-debianish? - Jonas Who agrees the package is in bad shape, but dislikes hijacking. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Jonas Smedegaard (31/05/2012): > I have heard before the argument of the sponsor having responsibility, > but in reality I have *never* heard of sponsors actually being held > responsible for anything but the concrete upload of a specific > packaging release. Suggested reading: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=37;bug=672117 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=59;bug=672117 The sponsor did almost all the needed work to reduce entropy (see the thread to see how many packages got delayed/entangled/prevented from migrating because of the initial upload). [ Holger, that's fingerpointing. Pointing to how you quickly dealt with those packages, thanks again. :-) ] Mraw, KiBi. signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 09:22am, Bernd Zeimetz wrote: > On 05/30/2012 11:11 AM, Jonas Smedegaard wrote: > It is better to have a well maintained package than to ait for > somebody who collected a number of NMUs and doesn't react to bug > reports for years. I perfectly agree. But it is better to have responsibly maintained packages having newest upstream code packaged at any cost. ...and I find both of our comparisons above too simplistic! On 12-05-31 at 09:22am, Bernd Zeimetz wrote: > On 05/30/2012 11:11 AM, Jonas Smedegaard wrote: > > 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 :-( > > You and a lot of others fail to realize that the *SPONSOR* is > responsible for the package. Huh?!? What does "Maintainer:" mean if not the entity being responsible for, well, maintaining?!? > If the maintainer fails to keep the package in a useful shape it is > the sponsor's responsibility to do so. And last but not least it > should be the sponsor's decision to orphan a package if the maintainer > is MIA or not doing his job properly. It is also the sponsors > responsibility to try to figure out if a maintainer is willing to do > his job longer than one upload before sponsoring a package at all. I have heard before the argument of the sponsor having responsibility, but in reality I have *never* heard of sponsors actually being held responsible for anything but the concrete upload of a specific packaging release. ...which leads to my concern for high 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. > > Yet another job for the sponsor. How can sponsor help create social pride (or social pressure if doing a lousy job)? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 10:06am, Andreas Tille wrote: > On Wed, May 30, 2012 at 06:03:05PM -0700, Steve Langasek wrote: > > There is no excuse for hijacking a package, ever. > > ... > > Hmm, this arguing sounds quite German to me. Rules are rules are > rules and you should not disregard them. So a German will wait in > front of a red traffic light even if there is no visible sign of any > car and no sound that might give some signal for any traffic. When I > was abroad I enjoyed the habit of other nations just to know when > breaking a rule makes perfectly sense. I also think that some common > sense could be applied in very obvious cases and this discussion shows > that several respected people do agree that there are cases like this > where there actually is an excuse for hijacking a package. I am danish, not german, and I wait at traffic lights, also at night. ...or sometimes I do. Pretty often I cross at red light, but am then prefectly aware that I break the rules, and I take eventual punishment for that [with a smile]. You can have _reasons_ for hijacking, but no reason is an excuse: It is never ok to hijack. Hijack is takeover without either explicit approval or community consensus. Following a community approved procedure for takeover without the explicit consent of the former maintainer it is not hijacking. Are we both talking about same meaning of "hijacking" and "excuse"? - Jonas [with a smile]: I also break the rules when abroad, and have fould that especially in USA my smiling risk escalating matters - the policemen get confused when I smile while they write a fine or [just a warning]. [just a warning]: A month ago I drove on a bike on the sidewalk in Brooklyn and nearly ran down three policemen standing at a corner. Surprisingly they only gave me a warning - I had expected a fine then. Thanks to Daniel Kahn Gilmore for lending me the bike! -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi Charles, On 12-05-31 at 08:29am, Charles Plessy wrote: > Le Wed, May 30, 2012 at 11:11:51AM +0200, Jonas Smedegaard a écrit : > > > > *nothing* qualifies for a hijacking. > > Dear Jonas, > > your reaction seems to imply that hijacking is an implicit statement > of failure. But this can be dis-ambiguated by thanking the maintainer > for his past work, bringing the package in a team where everybody is > welcome, which is not the same as moving it between two single > maintainers, and by underlining that the reason for transferring the > package to a team is that the mainainer, while not on vacation, could > not be contacted. No, my point is not about lack of recognition for past contributions. No, it is not about teams being welcoming or superior in others ways. It is about Debian not being the Wild West. I distinguish between "hijacking" and "friendly takeover" and "project overruling". What you describe is the proper way of a friendly takeover: You agree with the former maintainer to take over, and in the changelog entry formally announcing it you thank the former maintainer for the past efforts. It can be a person or a team taking over, and if the team also includes the former maintainer it might make sense to skip the "thank you" part. "project overruling" is when Debian by its defined procedures judge that the maintainer is unfit to maintain, and therefore relieve her/him/them of her/his/their duties, Hijacking, in my vocabulary, is when a non-maintainer takes matters in his/her/their own hands and takes over maintainership without the consent of the former maintainer and outside formal Debian procedures. > There is indeed a problem with packages not maintained by DDs as they > can not formally declare themselves on vacation, but search engines > would be able to find such a statement on mailing lists if it had been > posted. My non-Debian-member-as-maintainer rant is not about vacation notices, but about bonding and commitment. It's somewhat like making a baby versus having a baby: Making a Debian package requires certain skills, and some work once (for an hour or a year, depending on who you are). We dearly encourage anyone interested to try it out, and share with the results with us and the rest of the World. Having a package (a.k.a. being a Debian maintainer) additionally requires passion and devotion for a looong time - ideally for the full lifetime of the package. I don't mean to say that only the Debian elite should raise babies, others should use protection - that Debian members are better parents. My point is that the social structures of Debian matters for the quality of maintainance: When you do a poor job in Debian, you get remarks by your peers about it. When you do a poor job outside of Debian, there is silence. Your bonding with Debian helps you either care more or pass it on to someone who cares or get rid of the package. Debian should avoid elitism by welcoming newcomers to our village, not by encouraging raising kids in the jungle. > I think that it is important to have the flexibility to transfer a > package for which the maintainer is not responding, in a neutral way > that is not making any judgement on why he is not responding. I interpret "neutral way" as "through defined process" (i.e. our MIA process or the technical committee) rather than ad hoc. I disagree that we need a defined process for "not responding" regarding a single package as opposed to our "missing in action" affecting all packages a maintainer is involved in: I believe there is no common pattern for the special cases of a maintainer being active but irresponsible towards a subset of packages. MIA process should not be nosy: We should not care _why_, only _if_ a maintainer is not doing the job responsibly. I am unaware if current process is too nosy - but if so it seems ripe for improvements. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Wed, May 30, 2012 at 06:03:05PM -0700, Steve Langasek wrote: > There is no excuse for hijacking a package, ever. > ... Hmm, this arguing sounds quite German to me. Rules are rules are rules and you should not disregard them. So a German will wait in front of a red traffic light even if there is no visible sign of any car and no sound that might give some signal for any traffic. When I was abroad I enjoyed the habit of other nations just to know when breaking a rule makes perfectly sense. I also think that some common sense could be applied in very obvious cases and this discussion shows that several respected people do agree that there are cases like this where there actually is an excuse for hijacking a package. Kind regards Andreas. -- http://fam-tille.de -- 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/20120531080643.gb6...@an3as.eu
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/30/2012 11:11 AM, Jonas Smedegaard wrote: > 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 don't think that hijacking is *that* bad, especially not when its done by a team which welcomes the original maintainer. It is better to have a well maintained package than to ait for somebody who collected a number of NMUs and doesn't react to bug reports for years. > 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 :-( You and a lot of others fail to realize that the *SPONSOR* is responsible for the package. If the maintainer fails to keep the package in a useful shape it is the sponsor's responsibility to do so. And last but not least it should be the sponsor's decision to orphan a package if the maintainer is MIA or not doing his job properly. It is also the sponsors responsibility to try to figure out if a maintainer is willing to do his job longer than one upload before sponsoring a package at all. > ...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. Yet another job for the sponsor. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4fc71c48.7070...@bzed.de
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thu, May 31, 2012 at 02:01:51PM +0800, Thomas Goirand wrote: > Did you see me writing "I'd like to hijack php-codesniffer in order to rush > and get it into wheezy in time before the freeze"? *NO* ! I didn't write > that. Agreed. I'd have expected people, if anything, to answer suggesting the correct procedure to get things done in this case. I was surprised to see replies harshly escalating matters this way. My understanding is that we have a package that looks unmaintained for 4 years. Yelling at those who volunteer to do some work on it, instead of guiding them to do it in the best way, seems silly and rather un-debianish to me. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
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. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20120531062040.ga1...@rivendell.home.ouaza.com
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 05/31/2012 09:03 AM, Steve Langasek wrote: > If you're unhappy that the package has been unmaintained for a long time and > that the MIA process takes time to result in an orphaning... suck it up. If > it was actually a problem, someone would have noticed it earlier and done > something about it. An unmaintained package does not suddenly become an > urgent matter for the project the moment another DD notices it, and there is > *no* justification for bypassing our agreed-upon community processes for how > unmaintained packages are handled. > > 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. > Why are people talking about urgency and hijack? None applies to this package. Please refer to the title of this thread, where I wrote: Orphaning *THEN* take over Is there anything wrong with that? Please re-read my first post of this thread. Did you see me writing "I'd like to hijack php-codesniffer in order to rush and get it into wheezy in time before the freeze"? *NO* ! I didn't write that. That's not my intention, especially that this is a tool aimed at developers, so it doesn't really mater if it's not in Wheezy (it'd be nicer, but it's ok if it's not). In fact, it's the total opposite way, I asked others if they found it ok to ask for the package to be orphaned after only a week, because I thought that 4 years without a refresh of the package, multiple NMUs of other packages from the same maintainer, was enough to shorten the "ping period". I also wrote about my intention to get the original maintainer in the team if he wishes so. Then considering Jonas opinion, I agreed to leave one week more, even if I know that the orphaning process may take some time as well. Is this hijack? Is this rushing? Thomas -- 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/4fc7094f.8040...@debian.org
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Le Wed, May 30, 2012 at 06:03:05PM -0700, Steve Langasek a écrit : > > 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. I hereby report that I hijiacked bioperl and seaview. If you want me to step down as a maintainer of these packages, let me know, no need to vote, and no need to be appointed in a special commttee: everybody on this list has the power to demotivate others. Use it with care. -- Charles -- 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/20120531014153.gb3...@falafel.plessy.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Thu, May 31, 2012 at 08:29:34AM +0900, Charles Plessy wrote: > Le Wed, May 30, 2012 at 11:11:51AM +0200, Jonas Smedegaard a écrit : > > *nothing* qualifies for a hijacking. > your reaction seems to imply that hijacking is an implicit statement of > failure. There is no excuse for hijacking a package, ever. If the maintainer is MIA, use the MIA process to get the package orphaned. If the maintainer has not yet been shown to be MIA, do an NMU as needed. If you're unhappy that the package has been unmaintained for a long time and that the MIA process takes time to result in an orphaning... suck it up. If it was actually a problem, someone would have noticed it earlier and done something about it. An unmaintained package does not suddenly become an urgent matter for the project the moment another DD notices it, and there is *no* justification for bypassing our agreed-upon community processes for how unmaintained packages are handled. 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. 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. > But this can be dis-ambiguated by thanking the maintainer for his past > work, Empty words, > bringing the package in a team where everybody is welcome, and a corrossive fallacy. Teams work when there are shared processes and tools. By definition, you are proposing to give the current maintainer no say in the processes or tools to be used. > I think that it is important to have the flexibility to transfer a package > for which the maintainer is not responding, in a neutral way that is not > making any judgement on why he is not responding. We already have this process, documented in section 7.4 of the Developers' Reference. What you are discussing here is *bypassing* that process. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Le Wed, May 30, 2012 at 11:11:51AM +0200, Jonas Smedegaard a écrit : > > *nothing* qualifies for a hijacking. Dear Jonas, your reaction seems to imply that hijacking is an implicit statement of failure. But this can be dis-ambiguated by thanking the maintainer for his past work, bringing the package in a team where everybody is welcome, which is not the same as moving it between two single maintainers, and by underlining that the reason for transferring the package to a team is that the mainainer, while not on vacation, could not be contacted. There is indeed a problem with packages not maintained by DDs as they can not formally declare themselves on vacation, but search engines would be able to find such a statement on mailing lists if it had been posted. I think that it is important to have the flexibility to transfer a package for which the maintainer is not responding, in a neutral way that is not making any judgement on why he is not responding. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120530232934.gc19...@falafel.plessy.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-30 at 05:14pm, Jon Dowland wrote: > 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. The clock for questioning if maintainer might(!) be MIA started back then. The clock for hijacking never starts - that's not how Debian works! Specifically, bug#599617 is a wishlist issue, so no big deal in itself that it has gone unnoticed for ages. File bugs if bugs exist. Do the MIA process if that is deemed necessary. Don't hijack. Ever. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: 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 signature.asc Description: Digital signature
Re: 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 signature.asc Description: OpenPGP digital signature
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530161413.GA23744@debian
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Thomas Goirand 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vg9eopq.fsf@algernon.balabit
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc6238a.4070...@debian.org
Re: 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 signature.asc Description: Digital signature
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc59455.9060...@goirand.fr
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529234522.ga...@falafel.plessy.net
Re: 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 signature.asc Description: OpenPGP digital signature
Re: 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 signature.asc Description: Digital signature
Orphaning php-codesniffer, then take it over by the PHP PEAR team
Hi, Jack Bates is supposed to maintain php-codesniffer, available from: http://pear.php.net/package/PHP_CodeSniffer Unfortunately, the PTS for this package shows that this package last upload was from 2008-10-05, few months after version 1.1.0 was released upstream (on the 2008-07-14). Upstream has been releasing every 3 to 6 months since, but none of the upstream versions have been released. PHPUnit has been uploaded to SID, and will soon migrate to testing. This PHP_CodeSniffer is a good QA tool as well, and we'd like to see the latest version in Wheezy as well. 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. If anyone doesn't agree, please raise your concern *now* (including you, Jack). Cheers, Thomas Goirand (zigo) -- 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/4fc51a32.2020...@debian.org
