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

» Linux Archive

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


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-22-2010, 01:07 PM
Ana Guerrero
 
Default 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 <helen@debian.org>
Changed-By: Jari Aalto <jari.aalto@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 ${miscepends}.
- (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) <mhatta@debian.org>
Changed-By: Nobuhiro Iwamatsu <iwamatsu@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100522130720.GA1982@ana.debian.net">http://lists.debian.org/20100522130720.GA1982@ana.debian.net
 
Old 05-22-2010, 04:32 PM
tony mancill
 
Default 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 <helen@debian.org>
> Changed-By: Jari Aalto <jari.aalto@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 ${miscepends}.
> - (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) <mhatta@debian.org>
> Changed-By: Nobuhiro Iwamatsu <iwamatsu@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)
>
 
Old 05-22-2010, 05:20 PM
Julien BLACHE
 
Default Too much disruptive NMUs

tony mancill <tmancill@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 - <jblache@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87typz4zv9.fsf@sonic.technologeek.org">http://lists.debian.org/87typz4zv9.fsf@sonic.technologeek.org
 
Old 05-22-2010, 05:23 PM
Neil Williams
 
Default Too much disruptive NMUs

On Sat, 22 May 2010 09:32:02 -0700
tony mancill <tmancill@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
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 RM bug. If not, orphan the package and fix the RC bug and the other
issues as a QA upload.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
 
Old 05-22-2010, 05:33 PM
Neil Williams
 
Default Too much disruptive NMUs

On Sat, 22 May 2010 19:20:42 +0200
Julien BLACHE <jblache@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/
 
Old 05-23-2010, 06:06 AM
Christian PERRIER
 
Default Too much disruptive NMUs

Quoting Ana Guerrero (ana@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...)
- ${miscepends} 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 packages....and 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 reports....they just seem to
be living their life quietly in the archive without much need for attention..:-)
 
Old 05-23-2010, 06:40 AM
Lucas Nussbaum
 
Default 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
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100523064044.GA13311@xanadu.blop.info">http://lists.debian.org/20100523064044.GA13311@xanadu.blop.info
 
Old 05-23-2010, 07:39 AM
Lucas Nussbaum
 
Default 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
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100523073911.GA14801@xanadu.blop.info">http://lists.debian.org/20100523073911.GA14801@xanadu.blop.info
 
Old 05-23-2010, 07:56 AM
Jan Hauke Rahm
 
Default 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 <jblache@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 <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org
 
Old 05-23-2010, 08:01 AM
Jan Hauke Rahm
 
Default 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 <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org
 

Thread Tools




All times are GMT. The time now is 05:34 PM.

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