Re: Too much disruptive NMUs

[Osamu Aoki]

Hi,

On Sun, May 23, 2010 at 07:33:48PM +0200, Lucas Nussbaum wrote:
> On 24/05/10 at 01:15 +0900, Osamu Aoki wrote:
> > Really, issue is "Debian does not have reasonable rule for hijacking or
> > automatic orphaning".
> 
> I fully agree. There are many packages that are staying with totally
> outdated upstream versions simply because the maintainer went inactive,
> and MIA was not able to orphan his packages (because the maintainer,
> despite being inactive, might still reply "I will come back in a month
> and fix everything").
> 
> > If some maintainer is totally quiet on BTS report for over 2 months,
> > he should loose maintainer-ship.  The same goes if the maintainer has
> > not uploaded new upload after reminded by bug report for 2 months
> > without reply, he should loose maintainer-ship.  If he had "I am
> > maintaining this" without clear technical reason not-to-package new
> > version, this should apply too. (If he has real reason, of course he
> > should keep it.)
> 
> ... but I disagree with having a strict rule that allows everybody to
> hijack a package. I think that it should be the responsibility of the
> hijacker to prove that he made enough efforts to contact the maintainer,
> and that he is qualified to maintain the package.

I share your concern too.
 
> For example, the candidate hijacker could send an "intend to hijack foo"
> email to debian-devel@, with the reasons why he thinks the package
> should be hijacked (date of last maintainer upload, list of open bugs
> without any response from the maintainer, new upstream versions which
> were not packaged, MIA status, etc).
> That email would send receive public review, and if nobody objects after
> some time, the hijacker could proceed.

This is good procedure.  What I wanted is additional general guide line
for such an action.  Without it, I bet thee will be some personal
encounters.  (More detailed guide line may be needed.)

Osamu


-- 
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/20100524135434.gc4...@osamu.debian.net

Re: Too much disruptive NMUs

[Ana Guerrero]

Hi!

On Sun, May 23, 2010 at 10:01:22AM +0200, Jan Hauke Rahm wrote:
> On Sun, May 23, 2010 at 08:40:44AM +0200, Lucas Nussbaum wrote:
> > On 22/05/10 at 15:07 +0200, Ana Guerrero wrote:
> > > Hi,
> > > 
> > > It is good to care for packages from people who are currently too busy and
> > > making NMUs to fix critical/very important bugs. However, lately I have 
> > > been
> > > seeing a lot of NMUs that are being very disruptive [0], you have a 
> > > couple of
> > > examples below [1]. (This is not against Jari or Nobihuro, they are just 
> > > the 
> > > latest examples I have seen today).
> > > 
> > > I know this is done with the best intentions but if you think the package 
> > > is in bad shape or neglected by the maintainer then it might better write 
> > > to mia@, debian-qa@ or open a bug asking whether the package should be 
> > > orphaned (or even removed). Both examples below are candidates to be 
> > > orphaned.
> > > 
> > > If you think this kind of changes are good, please start a discussion 
> > > about
> > > changing this in the developers-reference.
> > 
> > Our standard process for addressing issues with such packages is the MIA
> > process. However, the MIA process takes quite a lot of time, and it has
> > happen in the past that it was completely stalled due to a lack of
> > manpower. Also, there are cases where the maintainer will respond to the
> > MIA team, preventing the orphaning of his packages, despite not working
> > on his packages.
> 
> Both true, unfortunately.

I suggested in my first email also "open a bug asking whether the package
should be orphaned" to avoid stalling possible qa-orphaning uploads. I really
think this is the way to go there.
A lot of people when notified about a NMU of their packages do nothing, because 
they are happy somebody else is caring about their packages while they are
busy.
However if the maintainer is really inactive and get an email asking if s/he
is still interested in working in the package it is different, you are being
asked something and you should answer.
This does not mean you should not mail the MIA team at the same time, but you 
do not need to wait action from them (specially if the maintainer agrees
on orphaning), and if we can help globally on removing some work from the
shoulders of the MIA team, the better :D
If the bug keeps unanswered you can ping after some time, it is kept open
even if you do a NMU and after some months without some action, it is time of
retitling it as an orphan bug.

Partially this solves the problem Lucas pointed here, when you have a few bugs 
like those open against a package and routinely closed by the maintainer 
saying "I am still interested I will work on it", you can see publically 
there is a pattern there...
Of course, private details keep going to the non public mia@ alias.


> > So, I think that preparing an NMU that fixes small problems in the
> > package at the same time as contacting the MIA team is a good thing. It
> > helps to improve the quality of Debian, and alleviates the problem of
> > temporarily busy maintainer.
> 
> Ack.

If you contact the MIA team we are not talking about a "temporarily
busy maintainer" we are talking about somebody who seems to have been MIA
for some time.
On my experience, a temporarily busy maintainer is somebody who tells 
you: "go ahead with your NMU I am busy" and usually this package does not need 
too many small fixes because it is more or less maintained.


> > I'd like to encourage Jari and Nobihuro to continue that work, but to
> > make sure that:
> > - they contact the MIA team about the maintainers of the packages they
> >   NMU
> > - the packages they NMU are really _useful_ and should be kept in Debian
> > - they don't NMU actively maintained packages by mistake. If there are
> >   documented efforts to contact the maintainer, using the DELAYED queue
> >   with a long delay would help with that.
> 
> Ack but still:
> 
> - don't be too disruptive!
> 
> I don't think that changing to dh7, i.e. debian/rules to the tiniest
> form, switching a package from dpatch to quilt to finally switch it to
> 3.0 (quilt) are changes that should be done, even if they seem useful.
> And there are more examples.
> 
> I guess the problem is, as usual, where to draw the line.

Yeah, we have here problems with the "don't be too disruptive" part, the 
concept of what a minimal changes seems to be *very* subjective :-)

Ana


-- 
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/20100523213425.ga30...@ana.debian.net

Re: Too much disruptive NMUs

[Ana Guerrero]

Hi Jari (also Tony and Nobuhiro):

On Sun, May 23, 2010 at 04:21:30PM +0300, Jari Aalto wrote:
> 

I am not going to answer you detailed to this email because you are trying
to explain you did nothing wrong and I agree you did nothing wrong 
trying to fix bug and improve the quality in the archive.
My original email mentioning your upload and Nobuhiro's was adding an example,
then I cc'ed you since I was mentioning you, and your point of view about
this was interesting for the discussion.

About your mail I want to mention that what your consider minor changes
are not minor changes for other people as you can see in this thread. 
And I want to highlight the idea that when you think a package is not 
properly maintained then you (we) should force orphaning it.  I am commenting
more about this in other thread.

If you think we should change the criteria about what is ok for a NMU or not,
please follow the thread in debian-qa.

I hope this mail explain my initial mail better and keep up the good work.

Ana


-- 
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/20100523191124.ga29...@ana.debian.net

Re: Too much disruptive NMUs

[Lucas Nussbaum]

On 24/05/10 at 01:15 +0900, Osamu Aoki wrote:
> Really, issue is "Debian does not have reasonable rule for hijacking or
> automatic orphaning".

I fully agree. There are many packages that are staying with totally
outdated upstream versions simply because the maintainer went inactive,
and MIA was not able to orphan his packages (because the maintainer,
despite being inactive, might still reply "I will come back in a month
and fix everything").

> If some maintainer is totally quiet on BTS report for over 2 months,
> he should loose maintainer-ship.  The same goes if the maintainer has
> not uploaded new upload after reminded by bug report for 2 months
> without reply, he should loose maintainer-ship.  If he had "I am
> maintaining this" without clear technical reason not-to-package new
> version, this should apply too. (If he has real reason, of course he
> should keep it.)

... but I disagree with having a strict rule that allows everybody to
hijack a package. I think that it should be the responsibility of the
hijacker to prove that he made enough efforts to contact the maintainer,
and that he is qualified to maintain the package.

For example, the candidate hijacker could send an "intend to hijack foo"
email to debian-devel@, with the reasons why he thinks the package
should be hijacked (date of last maintainer upload, list of open bugs
without any response from the maintainer, new upstream versions which
were not packaged, MIA status, etc).
That email would send receive public review, and if nobody objects after
some time, the hijacker could proceed.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
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/20100523173348.gb17...@xanadu.blop.info

Re: Too much disruptive NMUs

[Osamu Aoki]

Hi,

On Sat, May 22, 2010 at 06:23:25PM +0100, Neil Williams wrote:
> On Sat, 22 May 2010 09:32:02 -0700
> tony mancill  wrote:
> 
> > I sponsored the upload of a number of Jari's fixes.  You state that
> > they were disruptive, but I'm wondering to whom.  The uploads were to
> > delayed queues and the maintainer notified via the BTS, and in all
> > cases where the maintainer actually ACK'd the bug report or NMU, we
> > discussed the matter with the maintainer and/or removed the NMU from
> > the delayed queue.
> > 
> > In most cases (it may be all for the packages Jari and I worked on),
> > the maintainers never responded whatsoever to bug reports that were
> > over a year old, nor to the intent to NMU, so in a sense they could be
> > considered them QA uploads.  I.e., if a developer can't be bothered to
> > even respond to a bug in the Debian BTS, then the package is
> > essentially orphaned. 
> 
> Then the process, as I see it, would be for the person making the
> proposed NMU to file the bug to orphan the package instead, wait the
> length of time that the proposed upload would have waited in the
> delayed queue, or maybe a bit longer, and then make a QA upload (or
> adopt the package) without using the delayed queue.

I have made few NMU upload like this myself.

Maintainer was very quiet on BTS and not updating package at all for
something like a year.

But he always responded at the last moment that he wanted to keep the
maintainer position.  After a NMU and several months, it repeated and I
made delayed NMU and got the same response.  (I told him to orphan but
he practically rejected idea by action.)  Now I got him to accept me as
uploader, next upload may not be NMU but I feel this is not the optimal
situation.

Since original package had no-so-optimal cdbs usage and funny unused
codes, I decided to use dh7 and clean these up.  In the course, I
switched from cdbs -p0 patch to 3.0 (quilt).

Really, issue is "Debian does not have reasonable rule for hijacking or
automatic orphaning". If some maintainer is totally quiet on BTS report
for over 2 months, he should loose maintainer-ship.  The same goes if
the maintainer has not uploaded new upload after reminded by bug report
for 2 months without reply, he should loose maintainer-ship.  If he had
"I am maintaining this" without clear technical reason not-to-package
new version, this should apply too. (If he has real reason, of course he
should keep it.)

(I like idea of DM but DM should not think that their first upload
can be changing only "DM-Upload-Allowed: yes" without bug fix.  Is this
documnted somewhere?)

Osamu

PS: mail made with "From: os...@debian.org" got bounced.


-- 
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/20100523161537.ga32...@osamu.debian.net

Re: Too much disruptive NMUs

[Stefano Zacchiroli]

On Sun, May 23, 2010 at 05:09:32PM +0300, Jari Aalto wrote:
> - non-active maintainer and for case like: years old package, 6+
>   months old FTBFS, or ancient 3.[56].x policy in debian/control?

On -qa, we tried to define some time ago work-flow for dealing with
cases like that (essentially, how to have something "NMU-like" which
permits to orphan a package not being the maintainer, without inducing
too much steps, too much bottlenecks, etc.). Please take this discussion
to -qa if you're interested in helping out; you can start at
.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Too much disruptive NMUs

[Jari Aalto]

Alexander Wirt  writes:
>> Jari Aalto schrieb am Sunday, den 23. May 2010:
>>
>> [When package was not maintained]
>>
>> In addition to fixing the RC bugs, minor updates were usually done at
>> the same time. This was done for the reasons that in case the packages
>> were later orphaned or the maintainer were MIA, it would be more
>> desireable to have a well shaped package in archive. The minor changes
>> include:
>> 
>> - update to latest debhelper (In many times no debian/rules changes;
>>   possibly update deprecated dh_clean to dh_prep")
>> - use packaging format 3.0 (delete quilt if it was used)
>> - update compat to 7
>
> I don't find anything of them acceptable for an nmu.
>
>> The DEP1 does't specifially encourage fixing anything else than the BUG
>> at hand, and that's a very good rule for actively maintained packages.
>
> That dep thingys are no policy. imho these uploads violate the nmu policy.

It was later turned into policy.

So there is not room for discreet judgement for cases like:

- active maintainer

- non-active maintainer and for case like: years old package, 6+
  months old FTBFS, or ancient 3.[56].x policy in debian/control?

That'd be a loss, quality wise.

Jari


-- 
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/8739xid80z@jondo.cante.net

Re: Too much disruptive NMUs

[Stefano Zacchiroli]

On Sun, May 23, 2010 at 03:25:11PM +0200, Alexander Wirt wrote:
> > The DEP1 does't specifially encourage fixing anything else than the BUG
> > at hand, and that's a very good rule for actively maintained packages.
> That dep thingys are no policy. imho these uploads violate the nmu policy. 

Well, DEP1 got implemented in developer's reference, which kind of
define the NMU policy. However that's not the point IMO. At least
according to Tony reply I can see that the work-flow for NMU has been
followed properly for most parts (e.g. by using the DELAYED queue,
fixing important bugs---which *is* allowed by NMU guidelines, etc.).

The main problem is that the changes performed have been a bit too much
overzealous, even if with the best intentions. All would have been fine
if things like "switching to quilt" have been avoided, and we would have
been here thanking the NMU-ers.

All in all, I can also understand the desire to fix that kind of things
in a package which is clearly unmaintained, but that should come with an
upload which also orphan the package or change the maintainer (of course
according to the processes for that). The guiding principle AFAICT is
that when you NMU a package you generally hope that the proper
maintainer will eventually integrate your changes, that's why they
should be minimized. If, on the contrary, the package is de facto
orphaned, it's pointless to strive for minimality (but then, again, the
package should be orphaned or worse).


Finally, just a plea for everybody participating in this thread. NMU
guidelines should be followed properly, that's out of discussion.
Nevertheless please try not to discourage too much (properly done) NMUs,
as we've a big inertia problem in Debian about maintainers with
less-than-stellar reaction time, and NMUs are one of the best tools we
have to counter that.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Too much disruptive NMUs

[Alexander Wirt]

Jari Aalto schrieb am Sunday, den 23. May 2010:

Hi, 

*snip*
> In addition to fixing the RC bugs, minor updates were usually done at
> the same time. This was done for the reasons that in case the packages
> were later orphaned or the maintainer were MIA, it would be more
> desireable to have a well shaped package in archive. The minor changes
> include:
> 
> - update to latest debhelper (In many times no debian/rules changes;
>   possibly update deprecated dh_clean to dh_prep")
> - use packaging format 3.0 (delete quilt if it was used)
> - update compat to 7
I don't find anything of them acceptable for an nmu.
> The DEP1 does't specifially encourage fixing anything else than the BUG
> at hand, and that's a very good rule for actively maintained packages.
That dep thingys are no policy. imho these uploads violate the nmu policy. 

 
Alex


-- 
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/20100523132511.ge16...@lisa.snow-crash.org

Re: Too much disruptive NMUs

[Jari Aalto]

Ana Guerrero  writes:
>
> It is good to care for packages from people who are currently too busy and
> making NMUs to fix critical/very important bugs. However, lately I have been
> seeing a lot of NMUs that are being very disruptive

Hi Ana,

The packages I took under close look have been carefully selected and
any possible "active" were either contacted or notified about the
upcoming NMU. I also participated #debian-qa to ask for MIA of certain
people when in doubt.

Via email, those that I contacted, were happy to responded "OK" with the
changes.

We've coordinated the uploads with Tony during period of 3 months, for
the upcoming release. The uploads were always put to DELAYED/NN, and
extra time (14 days) were given for some packaged for developers to
react.

The debian/changes lists may look "verbose", but the actual chages are
really minor. I prefer explicit changelogs so that peer-review is
possible.

In addition to fixing the RC bugs, minor updates were usually done at
the same time. This was done for the reasons that in case the packages
were later orphaned or the maintainer were MIA, it would be more
desireable to have a well shaped package in archive. The minor changes
include:

- update to latest debhelper (In many times no debian/rules changes;
  possibly update deprecated dh_clean to dh_prep")
- use packaging format 3.0 (delete quilt if it was used)
- update compat to 7

The DEP1 does't specifially encourage fixing anything else than the BUG
at hand, and that's a very good rule for actively maintained packages.

However these uploads you were seeing were for packages that:

- had very old bugs
- or were not actively maintained (developer not seen in years).

So I felt a "shaping up" would be in the spirit of good maintenance.

Jari

[1] http://dep.debian.net/deps/dep1.html


-- 
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/87hblyg3dx@jondo.cante.net

Re: Too much disruptive NMUs

[Jan Hauke Rahm]

On Sat, May 22, 2010 at 06:33:41PM +0100, Neil Williams wrote:
> On Sat, 22 May 2010 19:20:42 +0200
> Julien BLACHE  wrote:
> 
> > Either it's a QA upload or it's a NMU, but it can't be "a bit of
> > both".
> > 
> > If the package is effectively not maintained anymore, it's up to the
> > MIA team to investigate and eventually decide to orphan the package.
> 
> Do we have to wait for the MIA team or is a complete lack of response
> to a request to NMU in the BTS sufficient reason for someone who is
> interested in the package to file the bug to orphan the package
> themselves? As long as someone is interested in the package, shouldn't
> an email to the MIA team be sufficient? Someone has to be fairly
> interested in a package to consider an NMU in the first place.

I don't think that one or two mails to the BTS are sufficient to declare
a maintainer MIA and thus do all kinds of QA stuff on their packages,
regardless if those contacts have been NMU requests or whatever. On the
other hand, I acknowledge the problem that the MIA process sometimes
takes so much time, the interested NMUer even looses interest again.

Anyway, a mail to MIA is highly appreciated. Not that we can do much
more but at least we can note that as another contact attempt which
*can* lead to faster processing after all.

> Does the MIA team take note of the WNPP reports of recently orphaned
> packages or is there a chance that an inactive maintainer whose only
> package is orphaned and then uploaded using QA, could drop off the
> radar of the MIA team? (Leaving the key in place but no packages.)

There isn't enough manpower to do archive wide checks. I do from time to
time random checks, one of which being for maintainers without packages.
They are interesting to us as we have DDs who work as e.g. porters but
don't have packages. But as Lucas said, this is basically DAM's work.

> > This kind of NMUs don't help; they just help the unmaintained stuff
> > fly below the MIA radar longer.
> 
> Agreed - so in addition to my last email, a QA upload like this, IMHO,
> should make sure that the MIA team are aware. I'd assume that, once
> contacted, the MIA team would be happy for the package to be adopted
> whilst the rest of the MIA process goes ahead.

Of course we are happy for every orphaned package to be adpoted. I,
personally, am not happy about packages being hijacked after one
unanswered NMU mail to the BTS. There are maintainers who really took
some time off without telling anyone. It's not good but it happens, and
we shouldn't take their packages away for one such mistake.

Hauke

-- 
 .''`.   Jan Hauke Rahmwww.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


signature.asc
Description: Digital signature

Re: Too much disruptive NMUs

[Jan Hauke Rahm]

On Sun, May 23, 2010 at 08:40:44AM +0200, Lucas Nussbaum wrote:
> On 22/05/10 at 15:07 +0200, Ana Guerrero wrote:
> > Hi,
> > 
> > It is good to care for packages from people who are currently too busy and
> > making NMUs to fix critical/very important bugs. However, lately I have been
> > seeing a lot of NMUs that are being very disruptive [0], you have a couple 
> > of
> > examples below [1]. (This is not against Jari or Nobihuro, they are just 
> > the 
> > latest examples I have seen today).
> > 
> > I know this is done with the best intentions but if you think the package 
> > is in bad shape or neglected by the maintainer then it might better write 
> > to mia@, debian-qa@ or open a bug asking whether the package should be 
> > orphaned (or even removed). Both examples below are candidates to be 
> > orphaned.
> > 
> > If you think this kind of changes are good, please start a discussion about
> > changing this in the developers-reference.
> 
> Our standard process for addressing issues with such packages is the MIA
> process. However, the MIA process takes quite a lot of time, and it has
> happen in the past that it was completely stalled due to a lack of
> manpower. Also, there are cases where the maintainer will respond to the
> MIA team, preventing the orphaning of his packages, despite not working
> on his packages.

Both true, unfortunately.

> So, I think that preparing an NMU that fixes small problems in the
> package at the same time as contacting the MIA team is a good thing. It
> helps to improve the quality of Debian, and alleviates the problem of
> temporarily busy maintainer.

Ack.

> I'd like to encourage Jari and Nobihuro to continue that work, but to
> make sure that:
> - they contact the MIA team about the maintainers of the packages they
>   NMU
> - the packages they NMU are really _useful_ and should be kept in Debian
> - they don't NMU actively maintained packages by mistake. If there are
>   documented efforts to contact the maintainer, using the DELAYED queue
>   with a long delay would help with that.

Ack but still:

- don't be too disruptive!

I don't think that changing to dh7, i.e. debian/rules to the tiniest
form, switching a package from dpatch to quilt to finally switch it to
3.0 (quilt) are changes that should be done, even if they seem useful.
And there are more examples.

I guess the problem is, as usual, where to draw the line.

Hauke

-- 
 .''`.   Jan Hauke Rahmwww.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


signature.asc
Description: Digital signature

Re: Too much disruptive NMUs

[Lucas Nussbaum]

On 22/05/10 at 18:33 +0100, Neil Williams wrote:
> Does the MIA team take note of the WNPP reports of recently orphaned
> packages or is there a chance that an inactive maintainer whose only
> package is orphaned and then uploaded using QA, could drop off the
> radar of the MIA team? (Leaving the key in place but no packages.)

The MIA team focuses on maintainers, not on Debian Developers. DDs who
don't maintain packages are out of the scope of the MIA team. I think
that the DAMs are tracking DDs who don't maintain packages since it is
possible that some of them are inactive DDs.

Also, it's easy to find e.g developers who haven't uploaded any of
the packages in unstable with their current key in the keyring:
select login, gecos from ldap
where expire='f' and fingerprint not in (
select fingerprint from sources, upload_history
where sources.source = upload_history.source
and sources.version = upload_history.version
and sources.distribution='debian' and sources.release='sid');
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
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/20100523073911.ga14...@xanadu.blop.info

Re: Too much disruptive NMUs

[Lucas Nussbaum]

On 22/05/10 at 15:07 +0200, Ana Guerrero wrote:
> Hi,
> 
> It is good to care for packages from people who are currently too busy and
> making NMUs to fix critical/very important bugs. However, lately I have been
> seeing a lot of NMUs that are being very disruptive [0], you have a couple of
> examples below [1]. (This is not against Jari or Nobihuro, they are just the 
> latest examples I have seen today).
> 
> I know this is done with the best intentions but if you think the package 
> is in bad shape or neglected by the maintainer then it might better write 
> to mia@, debian-qa@ or open a bug asking whether the package should be 
> orphaned (or even removed). Both examples below are candidates to be orphaned.
> 
> If you think this kind of changes are good, please start a discussion about
> changing this in the developers-reference.

Our standard process for addressing issues with such packages is the MIA
process. However, the MIA process takes quite a lot of time, and it has
happen in the past that it was completely stalled due to a lack of
manpower. Also, there are cases where the maintainer will respond to the
MIA team, preventing the orphaning of his packages, despite not working
on his packages.

So, I think that preparing an NMU that fixes small problems in the
package at the same time as contacting the MIA team is a good thing. It
helps to improve the quality of Debian, and alleviates the problem of
temporarily busy maintainer.

I'd like to encourage Jari and Nobihuro to continue that work, but to
make sure that:
- they contact the MIA team about the maintainers of the packages they
  NMU
- the packages they NMU are really _useful_ and should be kept in Debian
- they don't NMU actively maintained packages by mistake. If there are
  documented efforts to contact the maintainer, using the DELAYED queue
  with a long delay would help with that.

(Note that I witnessed one of Jari's uploads, and the procedure he
followed was fine in that regard).

> This one is not even fixing a serious bug:

So? NMUs are not only for serious bugs.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
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/20100523064044.ga13...@xanadu.blop.info

Re: Too much disruptive NMUs

[Christian PERRIER]

Quoting Ana Guerrero (a...@debian.org):

> I know this is done with the best intentions but if you think the package 
> is in bad shape or neglected by the maintainer then it might better write 
> to mia@, debian-qa@ or open a bug asking whether the package should be 
> orphaned (or even removed). Both examples below are candidates to be orphaned.

I have many of these in the packages I do NMU for l10n purposes.

My current policy is to fix my initial goal (debconf l10n) and a few
"obvious" QA things, by drawing the line to things I judge as
"enough non-disruptive":

- fixes in debian/copyright (GPL-2, missing complete copyright
statements...)
- ${misc:Depends} in dependencies
- move to "1.0" source format mentioned explicitly (I think that "3.0
(quilt)" would be "too much")
- when debhelper compat is 4 or below, either:
  - bump it to 5 if the packaging is tooc complicated for me to
  investigate
  - bump it to 7 with minimal changes (usually "dh_clean -k" ->
  dh_prep) for simple packagesand doing a little bit more check
  that it doesn't break anything (it generally doesn't as I of course
  do *not* change anything else in debian/rules)
- "_Choices" -> "__Choices" in debconf templates
- "Homepage:" in debian/control
- and any other lintian warning I consider "safe" to fix ("safe"
usually means that I am able to fix it in a couple of seconds...because
this is a change I already did in many other packages)


I do this because I regard l10n uploads (NMU or not) as QA uploads
already anyway.

I keep a full reference of packages I NMU'ed and I intend to spend a
few days in a near future in sending a notice to the MIA team about
those packages I NMU'ed this way without any sign of life from the
maintainer.

Several of these packages looks very loosely maintained. There, it's
harder to say whether there abandoned or not or if they should be
orphaned. I personnally see my own NMUs as a sign that the package
might be a good candidate for orphaning|removal. Still, most
often, these packages don't have many bug reportsthey just seem to
be living their life quietly in the archive without much need for attention..:-)



signature.asc
Description: Digital signature

Re: Too much disruptive NMUs

[Neil Williams]

On Sat, 22 May 2010 19:20:42 +0200
Julien BLACHE  wrote:

> Either it's a QA upload or it's a NMU, but it can't be "a bit of
> both".
> 
> If the package is effectively not maintained anymore, it's up to the
> MIA team to investigate and eventually decide to orphan the package.

Do we have to wait for the MIA team or is a complete lack of response
to a request to NMU in the BTS sufficient reason for someone who is
interested in the package to file the bug to orphan the package
themselves? As long as someone is interested in the package, shouldn't
an email to the MIA team be sufficient? Someone has to be fairly
interested in a package to consider an NMU in the first place.

Does the MIA team take note of the WNPP reports of recently orphaned
packages or is there a chance that an inactive maintainer whose only
package is orphaned and then uploaded using QA, could drop off the
radar of the MIA team? (Leaving the key in place but no packages.)

> This kind of NMUs don't help; they just help the unmaintained stuff
> fly below the MIA radar longer.

Agreed - so in addition to my last email, a QA upload like this, IMHO,
should make sure that the MIA team are aware. I'd assume that, once
contacted, the MIA team would be happy for the package to be adopted
whilst the rest of the MIA process goes ahead.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpqOcSFZFuV8.pgp
Description: PGP signature

Re: Too much disruptive NMUs

[Neil Williams]

On Sat, 22 May 2010 09:32:02 -0700
tony mancill  wrote:

> I sponsored the upload of a number of Jari's fixes.  You state that
> they were disruptive, but I'm wondering to whom.  The uploads were to
> delayed queues and the maintainer notified via the BTS, and in all
> cases where the maintainer actually ACK'd the bug report or NMU, we
> discussed the matter with the maintainer and/or removed the NMU from
> the delayed queue.
> 
> In most cases (it may be all for the packages Jari and I worked on),
> the maintainers never responded whatsoever to bug reports that were
> over a year old, nor to the intent to NMU, so in a sense they could be
> considered them QA uploads.  I.e., if a developer can't be bothered to
> even respond to a bug in the Debian BTS, then the package is
> essentially orphaned. 

Then the process, as I see it, would be for the person making the
proposed NMU to file the bug to orphan the package instead, wait the
length of time that the proposed upload would have waited in the
delayed queue, or maybe a bit longer, and then make a QA upload (or
adopt the package) without using the delayed queue.

> Freshening the packaging to generic best
> practices (or perhaps a better term is "defacto standards") - e.g.
> going to the quilt source format (which changes almost nothing),
> using a modern version of debhelper, freshening a debian/watch file,
> or adding standard fields to debian/control - makes things easier for
> everyone involved, whether it be Debian QA or the maintainer (should
> he or she every opt to reengage).

Those tasks are definitely QA tasks, not NMU IMHO - none of those tasks
would warrant an upload by anyone except the maintainer, either alone
or in combination. Any bug reports for such issues would be wishlist
severity, even a broken watch file is minor at best, unless ALSO allied
with a FTBFS or similar RC issue.

Once orphaned, the maintainer can always re-adopt the package - just as
easily as anyone else.

If the person doing the NMU does not seek to be maintainer of the
package concerned, I see no impediment to following the existing
orphan&QA method. If there is a chance that the uploader can be added
to Uploaders: for future maintenance, then it might as well be a case
that the orphaning bug report is retitled ITA -  the original
maintainer could be preserved in Maintainer: or Uploader:. Maintainers
who don't actively maintain their packages may well welcome a chance to
hand off the package to someone else, when they finally get time to
answer their BTS email.

To me, the changes made in the uploads to which Anna specifically
mentioned are not "minimal NMU's" but QA uploads. I've nothing against
the changes per se, except that as we are preparing for Squeeze, those
who do have time to make NMU's should do so for RC bugs and those who
do QA work should do it as QA work.

I wish I had the time to do RC NMU's myself, but right now that
resource is lacking in my own case. To those who do have time, please
work on RC NMU's and not QA uploads that pretend to be NMU's.

> I view the "absolute minimal changes" NMU process as designed for (and
> more appropriate for) actively maintained packages.  That is, the NMU
> process assumes that there is a developer on the other end who
> actually maintains the package. 

In that case, use the process designed for packages that are not
maintained - orphaning and QA.

> I do agree that the work, all of
> which were either FTBFS or transition-related, could have been
> coordinated through Debian QA. 

FTBFS? If it was, why were the bugs not RC? These looked like bugs that
might become FTBFS in a little more time but were not right now. That's
QA work IMHO.

> In hindsight that may have been a
> better approach.  I am interested to hear QA's perspective; is it QA
> that finds the uploads disruptive?

This may be too simplistic, but this is how I see the question:

Non-RC bugs:
==

If the package is actively maintained (maintainer responds to BTS
emails about an NMU), then if someone else is to make an upload, that is
an NMU. (A busy maintainer who allows the NMU would presumably be open
to either having the new person as Uploader or letting go of the package
itself.)

If the package is not actively maintained (specifically if the
maintainer does not respond to the BTS & an orphan bug report), then
the upload needs to be a QA upload before the non-RC bug can be fixed
and other issues resolved.

RC buggy packages:
===

If the bug report is RC, fix it as an NMU with no changes other than
the specific fix for that bug - explicitly not making minor changes
like adding / changing VCS fields in debian/control and without making
major changes like bumping the version of debhelper. If a package with
RC bugs is not lintian clean, that isn't something an RC NMU should
seek to fix IMHO.

If the package is in such a bad state that it needs lots of QA work as
well, consider if the RC bug should be cloned against ftp.debian.org as
an R

Re: Too much disruptive NMUs

[Julien BLACHE]

tony mancill  wrote:

Hi,

> I view the "absolute minimal changes" NMU process as designed for (and
> more appropriate for) actively maintained packages.  That is, the NMU

Either it's a QA upload or it's a NMU, but it can't be "a bit of
both".

If the package is effectively not maintained anymore, it's up to the MIA
team to investigate and eventually decide to orphan the package.

This kind of NMUs don't help; they just help the unmaintained stuff fly
below the MIA radar longer.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
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/87typz4zv9@sonic.technologeek.org

Re: Too much disruptive NMUs

[tony mancill]

Hi Ana,

I'm happy to start the discussion.

I sponsored the upload of a number of Jari's fixes.  You state that they
were disruptive, but I'm wondering to whom.  The uploads were to delayed
queues and the maintainer notified via the BTS, and in all cases where
the maintainer actually ACK'd the bug report or NMU, we discussed the
matter with the maintainer and/or removed the NMU from the delayed queue.

In most cases (it may be all for the packages Jari and I worked on), the
maintainers never responded whatsoever to bug reports that were over a
year old, nor to the intent to NMU, so in a sense they could be
considered them QA uploads.  I.e., if a developer can't be bothered to
even respond to a bug in the Debian BTS, then the package is essentially
orphaned.  Freshening the packaging to generic best practices (or
perhaps a better term is "defacto standards") - e.g. going to the quilt
source format (which changes almost nothing), using a modern version of
debhelper, freshening a debian/watch file, or adding standard fields to
debian/control - makes things easier for everyone involved, whether it
be Debian QA or the maintainer (should he or she every opt to reengage).

I view the "absolute minimal changes" NMU process as designed for (and
more appropriate for) actively maintained packages.  That is, the NMU
process assumes that there is a developer on the other end who actually
maintains the package.  I do agree that the work, all of which were
either FTBFS or transition-related, could have been coordinated through
Debian QA.  In hindsight that may have been a better approach.  I am
interested to hear QA's perspective; is it QA that finds the uploads
disruptive?

Thank you,
tony

On 05/22/2010 06:07 AM, Ana Guerrero wrote:
> 
> Hi,
> 
> It is good to care for packages from people who are currently too busy and
> making NMUs to fix critical/very important bugs. However, lately I have been
> seeing a lot of NMUs that are being very disruptive [0], you have a couple of
> examples below [1]. (This is not against Jari or Nobihuro, they are just the 
> latest examples I have seen today).
> 
> I know this is done with the best intentions but if you think the package 
> is in bad shape or neglected by the maintainer then it might better write 
> to mia@, debian-qa@ or open a bug asking whether the package should be 
> orphaned (or even removed). Both examples below are candidates to be orphaned.
> 
> If you think this kind of changes are good, please start a discussion about
> changing this in the developers-reference.
> 
> Ana
> 
> 
> [0] http://www.debian.org/doc/developers-reference/pkgs.html#nmu
> 
> [1] 
> 
> This one is not even fixing a serious bug:
> 
> Format: 1.8
> Date: Tue, 04 May 2010 21:39:32 +0300
> Source: xwrits
> Binary: xwrits
> Architecture: source i386
> Version: 2.21-6.1
> Distribution: unstable
> Urgency: low
> Maintainer: Helen Faulkner 
> Changed-By: Jari Aalto 
> Description: 
>  xwrits - reminds you to take a break from typing
> Closes: 579038
> Changes: 
>  xwrits (2.21-6.1) unstable; urgency=low
>  .
>[ Jari Aalto ]
>* Non-maintainer upload.
>  - Move to packaging format "3.0 (quilt)".
>* debian/clean
>  - Mew file.
>* debian/compat
>  - New file.
>* debian/control
>  - (Build-Depends): update obsolete xutils to xutils-dev.
>(important; Closes: #579038). Remove *-1 version suffix
>from texinfo dependency. Update to debhelper 7.1.
>  - (Depends): add ${misc:Depends}.
>  - (Homepage): New field.
>  - (Standards-Version): update to 3.8.4.
>* debian/copyright
>  - Update layout and point to GPL-2.
>* debian/rules
>  - Delete EOL whitespaces.
>  - (DH_COMPAT): Remove.
>  - (install): Update dh_clean to dh_prep.
>  - (clean): Fix lintian debian-rules-ignores-make-clean-error.
>* debian/source/format
>  - New file.
>* debian/watch
>  - New file.
>* xwrits.1
>  - Fix hyphens.
> 
> ---
> 
> Format: 1.8
> Date: Fri, 14 May 2010 11:28:10 +0900
> Source: a2ps
> Binary: a2ps
> Architecture: source i386
> Version: 1:4.14-1.1
> Distribution: unstable
> Urgency: low
> Maintainer: Masayuki Hatta (mhatta) 
> Changed-By: Nobuhiro Iwamatsu 
> Description: 
>  a2ps   - GNU a2ps - 'Anything to PostScript' converter and pretty-printer
> Closes: 487183 507293 547907 557775 571571
> Changes: 
>  a2ps (1:4.14-1.1) unstable; urgency=low
>  .
>* Non-maintainer upload.
>* Update debian/control.
>   - Bump Standards-Version to 3.8.4
>   - Update Build-Depends on debhelper 7
>   - Update Depends on emacs23 instead of emacs22. (Closes: #571571)
> * Add debian/source/format.
>   Set source format to "1.0".
> * Update debian/compat to 7
> * Update debian/copyright
>   - Add year of Copyright.
>   - Fix copyright-without-copyright-notice lintian warning.
> * Update debian/rules
>   - Remove -k from dh_clean
>   - Remove usr/share/info/di

Too much disruptive NMUs

[Ana Guerrero]

Hi,

It is good to care for packages from people who are currently too busy and
making NMUs to fix critical/very important bugs. However, lately I have been
seeing a lot of NMUs that are being very disruptive [0], you have a couple of
examples below [1]. (This is not against Jari or Nobihuro, they are just the 
latest examples I have seen today).

I know this is done with the best intentions but if you think the package 
is in bad shape or neglected by the maintainer then it might better write 
to mia@, debian-qa@ or open a bug asking whether the package should be 
orphaned (or even removed). Both examples below are candidates to be orphaned.

If you think this kind of changes are good, please start a discussion about
changing this in the developers-reference.

Ana


[0] http://www.debian.org/doc/developers-reference/pkgs.html#nmu

[1] 

This one is not even fixing a serious bug:

Format: 1.8
Date: Tue, 04 May 2010 21:39:32 +0300
Source: xwrits
Binary: xwrits
Architecture: source i386
Version: 2.21-6.1
Distribution: unstable
Urgency: low
Maintainer: Helen Faulkner 
Changed-By: Jari Aalto 
Description: 
 xwrits - reminds you to take a break from typing
Closes: 579038
Changes: 
 xwrits (2.21-6.1) unstable; urgency=low
 .
   [ Jari Aalto ]
   * Non-maintainer upload.
 - Move to packaging format "3.0 (quilt)".
   * debian/clean
 - Mew file.
   * debian/compat
 - New file.
   * debian/control
 - (Build-Depends): update obsolete xutils to xutils-dev.
   (important; Closes: #579038). Remove *-1 version suffix
   from texinfo dependency. Update to debhelper 7.1.
 - (Depends): add ${misc:Depends}.
 - (Homepage): New field.
 - (Standards-Version): update to 3.8.4.
   * debian/copyright
 - Update layout and point to GPL-2.
   * debian/rules
 - Delete EOL whitespaces.
 - (DH_COMPAT): Remove.
 - (install): Update dh_clean to dh_prep.
 - (clean): Fix lintian debian-rules-ignores-make-clean-error.
   * debian/source/format
 - New file.
   * debian/watch
 - New file.
   * xwrits.1
 - Fix hyphens.

---

Format: 1.8
Date: Fri, 14 May 2010 11:28:10 +0900
Source: a2ps
Binary: a2ps
Architecture: source i386
Version: 1:4.14-1.1
Distribution: unstable
Urgency: low
Maintainer: Masayuki Hatta (mhatta) 
Changed-By: Nobuhiro Iwamatsu 
Description: 
 a2ps   - GNU a2ps - 'Anything to PostScript' converter and pretty-printer
Closes: 487183 507293 547907 557775 571571
Changes: 
 a2ps (1:4.14-1.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Update debian/control.
  - Bump Standards-Version to 3.8.4
  - Update Build-Depends on debhelper 7
  - Update Depends on emacs23 instead of emacs22. (Closes: #571571)
* Add debian/source/format.
  Set source format to "1.0".
* Update debian/compat to 7
* Update debian/copyright
  - Add year of Copyright.
  - Fix copyright-without-copyright-notice lintian warning.
* Update debian/rules
  - Remove -k from dh_clean
  - Remove usr/share/info/dir after installing.
* Add new patches.
  - Fix patch-system-but-direct-changes-in-diff
06_encoding_texi.dpatch, 07_a2ps_info.dpatch
  - Fix manpage-has-errors-from-man.
08_man.dpatch
* Update debian/emacsen-startup.
  (Closes: #557775, #507293, #547907, #487183)


-- 
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/20100522130720.ga1...@ana.debian.net