Re: Too much disruptive NMUs
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
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
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
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
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 Rahm j...@debian.org www.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
On Sat, May 22, 2010 at 06:33:41PM +0100, Neil Williams wrote: On Sat, 22 May 2010 19:20:42 +0200 Julien BLACHE jbla...@debian.org 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 Rahm j...@debian.org www.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
Ana Guerrero a...@debian.org 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
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
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 formo...@formorer.de 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
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
http://lists.debian.org/debian-qa/2010/05/msg00045.html.
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
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 tmanc...@debian.org 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
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
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
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
Too much disruptive NMUs
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 he...@debian.org
Changed-By: Jari Aalto jari.aa...@cante.net
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) mha...@debian.org
Changed-By: Nobuhiro Iwamatsu iwama...@debian.org
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
Re: Too much disruptive NMUs
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 he...@debian.org
Changed-By: Jari Aalto jari.aa...@cante.net
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) mha...@debian.org
Changed-By: Nobuhiro Iwamatsu iwama...@debian.org
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
Re: Too much disruptive NMUs
tony mancill tmanc...@debian.org 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 - jbla...@debian.org Public key available on http://www.jblache.org - 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
On Sat, 22 May 2010 09:32:02 -0700 tony mancill tmanc...@debian.org 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 orphanQA 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 RM bug. If not,
Re: Too much disruptive NMUs
On Sat, 22 May 2010 19:20:42 +0200 Julien BLACHE jbla...@debian.org 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
