Re: Self-assessment of the quality of the maintenance work

[Raphael Hertzog]

On Sat, 20 Dec 2008, Enrico Zini wrote:
> I quite liked the idea of allowing to set such attributes in the control
> file because, rather than looking like someone putting their nose on how
> one maintains packages, they are a handy way to document the
> maintainer's intentions with the package, providing a service to the
> maintainer: for example, if I mark a package dead-upstream, then people
> posting wishlist bugs will hopefully take that into account (and
> reportbug may remind them about it).  People adopting a "fringe" package
> for heavy production will have been warned and hopefully will do some
> extra testing, and so on.

Both approachs are probably complementary. Using the control file works
fine for things which are specific to the package (dead-upstream) or when
there is only one maintainer but when you have a package with multiple
maintainers, the active/passive classification is really different for
each maintainer.

The goal is also to discover cases where we have several co-maintainers
where everyone thinks that they are backup maintainers and that it's the
duty of someone else to handle this bug. For this, debian/control is not
suited at all.

And when creating the debtags data, we need to have some rules to merge
the views of each co-maintainer in a global coherent view.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Self-assessment of the quality of the maintenance work

[Raphael Hertzog]

On Sun, 21 Dec 2008, Filippo Giunchedi wrote:
> I like the general idea, here are a few points/questions:
> 
> Have a procedure to not receive the mail in the future (perhaps making it
> possible to (manually, via email?) re-enable at some later time)

The best results are achieved if everyone participates so I'd rather find
ways to make it painless for everybody first. But knowing how diverse the
opinions are, we will probably have to do something like this.

In that case, if someone opts-out, it might be interesting to have
heuristics to replace the missing data.

> > If the maintainer doesn't respond, he automatically enters the MIA
> > process and the package is quickly marked as needing help/attention
> > from someone else.
> 
> How long is the time span after the maintainer enters MIA? Perhaps after X
> unanswered mails?

No idea, that's up for discussions.

The system would try to not send emails when someone is in VAC. But yes, “a
ping every X weeks and if Y pings are left unanswered then he enters the
MIA process” could be ok.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Self-assessment of the quality of the maintenance work

[Raphael Hertzog]

On Sat, 20 Dec 2008, Russ Allbery wrote:
> Raphael Hertzog  writes:
> 
> > The basic idea is quite simple, we want to ensure that each package is
> > maintained as well as possible and for this we need to ensure that
> > it has one or more active maintainer(s). Hence every X months, each
> > maintainer receives a mail with a link to a web form where he'll have a
> > list of all the packages that he maintains/co-maintains and for each
> > package he has to answer several questions that explain his relationship
> > with the package (the answer are preseeded with the values he selected
> > the previous time so that he can quickly skim over it if nothing has
> > changed):
> 
> That's going to be a lot of fairly mindless paperwork for someone who's
> the member of a large, active team with a lot of packages.  For example, I
> feel for Gregor Herrmann (253 packages) or Gunnar Wolf (187 packages)
> having to fill this out for every package they uploaded for pkg-perl.

Agreed. I'm not sure what's the best way to handle this.

Maybe the form should make it easy to give the same answers to all
packages that are maintained by a given team ? We could use easily
identify the team by finding out an email that matches @lists\. in
either the Maintainer: field or the Uploaders: field.

Another answer might be to hide all packages which are fine under the
current norms (to be defined: no bugs (or less than X bugs), no lintian
errors, …) and use some predefined answers in those cases. The form would 
focus on packages with problems (or that are getting worse over time).

Do you see any other approach ?

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Self-assessment of the quality of the maintenance work

[Stefano Zacchiroli]

On Sat, Dec 20, 2008 at 06:19:26PM +0100, Raphael Hertzog wrote:
> I would like to propose something new that would partially supersede
> the work done by the MIA team and that would also generate new
> information somehow related to the topic of WNPP.

Well, I like the principle (who having a feeling of QA problems in
Debian wouldn't?) but I don't think the mechanism you are proposing
would work at all.

- the first time you'll ask people to fill the forms the mechanism
  will suck up a lot of time to everybody. As the benefits for the
  filler are not clear (at least not yet) they wouldn't be motivated
  to spend the required time

- the "fear" of getting bothered/pinged periodically via mail is
  something which is real among maintainers (remember all the fuss
  about DDPO via email? I think the fuss was inappropriate, but still
  it was there). This is another ingredient which will contribute "bad
  marketing" to such an initiative.

Unfortunately, I have the feeling that your proposal will work
properly only if an amount of people close to everybody will take part
in it, otherwise it won't be that useful, because most likely only the
active people will take part in it.

Alternative proposal


If the goal is cleaning up the maintainer/uploaders field I've an
alternative proposal which is, IMO of course, more likely to work
properly and do not require active work from the single maintainer. It
boils down to automatically filling the Uploaders field on the basis
of debian/changelog. (The idea is shamelessly copied from the GNOME
team.)

That would be an inherent, always up to date wrt contributions measure
of who worked on a given package recently. The outcome wouldn't be as
fine-grained as yours (passive / backup / ...), but it would be
automated.

What it would be needed (warning: braindump ahead) is:

- implementing it in some low-level tool, because we can't rely on
  CDBS class, it should (if agreed upon via something like a DEP) be
  fully automatica

- decide the thresholds for being listed in Uploaders

Orthogonal problems
---

After writing the above, I realized there are two orthogonal
problems. One is cleaning up Uploaders, which I believe would be
addressed by the above approach.

The other is identifying de facto orphaned packages. For that you can
indeed ping, but it can be way easier than what you propose. Just send
an email (with no web link whatsover), at most once per year, and only
mentioning packages which have not been touched by the maintainer for
more than 1 year. The reply can be formatted enabling the maintainer
to mention which packages she still maintains.

No reply = orphaned package.

Actually, your proposal mentions MIA, I don't get why. A maintainer
can have de facto orphaned some packages and still be active on
others.

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

please unblock net-snmp

[Filippo Giunchedi]

As per subject.
Relevant diff:

diff -u net-snmp-5.4.1~dfsg/debian/snmpd.init 
net-snmp-5.4.1~dfsg/debian/snmpd.init
--- net-snmp-5.4.1~dfsg/debian/snmpd.init
+++ net-snmp-5.4.1~dfsg/debian/snmpd.init
@@ -40,12 +40,12 @@
   start)
 echo -n "Starting network management services:"
 if [ "$SNMPDRUN" = "yes" -a -f /etc/snmp/snmpd.conf ]; then
-   start-stop-daemon --quiet --start --exec /usr/sbin/snmpd \
+   start-stop-daemon --quiet --start --oknodo --exec /usr/sbin/snmpd \
-- $SNMPDOPTS
echo -n " snmpd"
 fi
 if [ "$TRAPDRUN" = "yes" -a -f /etc/snmp/snmptrapd.conf ]; then
-   start-stop-daemon --quiet --start --exec /usr/sbin/snmptrapd \
+   start-stop-daemon --quiet --start --oknodo --exec /usr/sbin/snmptrapd \
-- $TRAPDOPTS
echo -n " snmptrapd"
 fi
diff -u net-snmp-5.4.1~dfsg/debian/changelog 
net-snmp-5.4.1~dfsg/debian/changelog
--- net-snmp-5.4.1~dfsg/debian/changelog
+++ net-snmp-5.4.1~dfsg/debian/changelog
@@ -1,3 +1,13 @@
+net-snmp (5.4.1~dfsg-12) unstable; urgency=high
+
+  * Urgency high because of RC bug fix.
+  * Modify start action so it doesn't fail if the service is already running.
+(Closes: #505237)
+  * Update Romanian translation (Closes: #505767)
+Thanks to Eddy Petrișor .
+
+ -- Jochen Friedrich   Tue, 16 Dec 2008 15:29:28 +0100
+
 net-snmp (5.4.1~dfsg-11) unstable; urgency=high
 
   * This update fixes the following security issue:

unblock net-snmp/5.4.1~dfsg-12

thanks,
filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:

I always keep the Titanic in mind when I talk about security or
safety, meaning that nothing is fully secure.
-- Anonymous (?)


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: please unblock net-snmp

[Filippo Giunchedi]

On Sun, Dec 21, 2008 at 12:05:40PM +0100, Filippo Giunchedi wrote:
> As per subject.

As you might have figured out, this was a mistake.

13:26   godog: :) @ your -qa mail :)
13:27   KiBi: heh, I should properly wake up before looking at RCs :)
13:28   :)

filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:

Recursion is the root of computation since it trades description for time.
-- Alan Perlis


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Monitoring debian/shlibs.local files?

[Cyril Brulebois]

Hello,

context: debian/shlibs.local can be used to work around broken shlibs
files (Policy §8.6.5). Bugs are supposed to be filed, then fixed, and
shlibs.local files should then disappear.

I'm wondering whether it might be a good idea to track those in source
packages, so as to make sure bugs got filed, and that those files go
away. Having a fixed shlibs file would be profitable to all packages
linking against this library, rather than having a single package
getting its dependencies properly, through its shlibs.local file.

Do you think it'd be worse the effort? (Didn't check the amount of such
files yet, still performing my first AM steps.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Propose remove waproamd from lenny

[Luk Claes]

Hi

Maybe this package should be removed from unstable?

Cheers

Luk

Jonathan Wiltshire wrote:
> I have just been trying to make roaming wireless work on my laptop and
> came across waproamd, which sounded great. However, further digging
> reveals that it has been obsoleted upstream and the original maintainer
> recommends wpa_supplicant instead. Quote:
> 
> "waproamd is obsolete, please use wpa_supplicant instead. waproamd
> contains some race conditions that are impossible to fix. wpa_supplicant
> supersedes waproamd in almost every way." [1]
> 
> waproamd is currently in stable, testing and unstable but has been
> orphaned since January this year. Popcon reports 150 votes, which I
> don't think is sufficient to try and maintain security updates for.
> 
> Removing waproamd from lenny will hopefully save some other users the
> same waste of time that I spent reading up on it.
> 
> [1] http://www.0pointer.de/lennart/projects/waproamd/


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Monitoring debian/shlibs.local files?

[Loïc Minier]

On Sun, Dec 21, 2008, Cyril Brulebois wrote:
> I'm wondering whether it might be a good idea to track those in source
> packages, so as to make sure bugs got filed, and that those files go
> away. Having a fixed shlibs file would be profitable to all packages
> linking against this library, rather than having a single package
> getting its dependencies properly, through its shlibs.local file.

 I'm all for it; over time I came across a bunch of broken packages
 due to shlibs.local files, or simply with the risk of these files
 bitrotting and causing issues later.

 Just like we have descriptions for patches, we could require a
 description for shlibs.local, perhaps with a #xx bug in the text;
 when enough packages drop shlibs.local or implement the comment, we can
 add a lintian tag.  I would expect not too many packages should keep it
 though; it's probably cruft in most cases.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Monitoring debian/shlibs.local files?

[Cyril Brulebois]

Loïc Minier  (21/12/2008):
> I'm all for it; over time I came across a bunch of broken packages
> due to shlibs.local files, or simply with the risk of these files
> bitrotting and causing issues later.

OK, since it doesn't look like useless, I'll look into it and report
back in a moment.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Monitoring debian/shlibs.local files?

[Cyril Brulebois]

Cyril Brulebois  (21/12/2008):
> OK, since it doesn't look like useless, I'll look into it and report
> back in a moment.

Attached, a list (103 source packages) based on the contents of
gluck:/org/lintian.debian.org/laboratory/source/*/debfiles/shlibs.local

(generated by the Makefile in ~kibi/shlibs-check.git, on gluck.)

As mentioned by Raphaël on IRC: a number of those are probably due to a
previous limitation of dpkg WRT generation of intradependencies
(binaries from the same source package).

Mraw,
KiBi.
adns:
=
libadns 1 libadns1


adolc:
==
libadolc 0 libadolc0


barnowl:

libzephyr 3 libzephyr3


blas:
=
libblas 3gf libblas3gf | libblas.so.3gf | libatlas3gf-base


cdebconf:
=
libdebconf 1.0 libdebconf1


console-tools:
==
libconsole  0   libconsole (= ${Source-Version})
libcfont0   libconsole (= ${Source-Version})
libctutils  0   libconsole (= ${Source-Version})


control-center:
===
libgnome-window-settings 1 libgnome-window-settings1 (>= 1:2.17.5)


courierpassd:
=
libcourierauth 0 courier-authlib (>= 0.58-3)


courierpasswd:
==
libcourierauth 0 courier-authlib (>= 0.58-3)


courieruserinfo:

libcourierauth 0 courier-authlib (>= 0.58-3)


diagnostics:

libdiagnostics 0 libdiagnostics0


e2fsprogs:
==
libext2fs   2
libe2p  2
libuuid 1
libcom_err  2
libss   2
libblkid1


eb:
===
libeb 12 libeb12


elmo:
=
# Dpkg shlibs override file
#
# Entries in this file will override all others, only use if you
# are really sure that is what you want!
# 
# For more information see the dpkg-shlibdeps manual page. 
#
# The format used is:
# 
#
# Example:
#   libfoo 1libfoo1 (>= 1.0-1)
#
libncurses  libncurses.so.5 libncurses5 (>= 5.3.20030719-1)


festival:
=
libestools 1.2 libestools1.2 (>= 1:1.2.96~beta-2)


freecell-solver:

libfreecell-solver 0 libfreecell-solver0 (>= 2.0.0)


ftplib:
===
# Make ftplib-dev depend on the exact version (Policy section 8.5).
# Other packages will use the shlibs file generated by dh_makeshlibs.
libftp  3   ftplib3 (= ${Source-Version})


gail:
=
libgailutil 18 libgail18 (>= 1.9.1)


gatos:
==
libgatos 0 libgatos0 (>= 0.0.5)


geoip:
==
libgeoip1 1.4.4 libgeoip1 (>> 1.4.4-0), libgeoip1 (<< 1.4.4-99)


glew:
=
libGLEW 1.5 libglew1.5


gnome-randr-applet:
===
libXrandr   r   xlibs (>> 4.3.0)


gnucash:

libgncgnome 0
libgw-core-utils 0
libcore-utils 0
libgw-gnc 0
libgncmodule 0
libgnc-app-file-gnome 0
libgnc-business-ledger 0
libgncmod-app-file 0
libgncmod-app-utils 0
libgncmod-backend-file 0
libgncmod-binary-import 0
libgncmod-business-backend-file 0
libgncmod-business-core 0
libgncmod-business-gnome 0
libgncmod-business-utils 0
libgncmod-calculation 0
libgncmod-dialog-tax-table 0
libgncmod-engine 0
libgncmod-generic-import 0
libgncmod-gnome-search 0
libgncmod-gnome-utils 0
libgncmod-ledger-core 0
libgncmod-locale-reports-us 0
libgncmod-network-utils 0
libgncmod-ofx 0
libgncmod-qif-import 0
libgncmod-register-core 0
libgncmod-register-gnome 0
libgncmod-report-gnome 0
libgncmod-report-system 0
libgncmod-standard-reports 0
libgncmod-stylesheets 0
libgncmod-tax-us 0
libgncmod-utility-reports 0
libgw-app-file 0
libgw-app-utils 0
libgw-binary-import 0
libgw-business-core 0
libgw-business-gnome 0
libgw-dialog-tax-table 0
libgw-engine 0
libgw-gnc-module 0
libgw-gnome-search 0
libgw-gnome-utils 0
libgw-kvp 0
libgw-register-core 0
libgw-report-gnome 0


gsnmp:
==
libgsnmp0 0.1.0 libgsnmp0 (>> 0.1.0-0), libgsnmp0 (<< 0.1.0-99)


guile-gnome-platform:
=
libguile-gnome-gobject-0 0 guile-gnome0-glib


hotkeys:

libdb2  2   libdb2 (>= 2.7.7)
libxml2 2   libxml2 (>= 2.2.8)


iaxclient:
==
libspeex 1 libspeex1 (>= 1.1.10-1)


iceape:
===
libnss3 0d libnss3-0d (>= 3.11.5-1)
libsmime3 0d libnss3-0d (>= 3.11.5-1)
libsoftokn3 0d libnss3-0d (>= 3.11.5-1)
libssl3 0d libnss3-0d (>= 3.11.5-1)


im-sdk:
===
libiiimcf 3 libiiimcf3 (>= 12.3)
libiiimp 1 libiiimp1 (>= 12.3)


itcl3:
==
libitcl3.2  1   
libitk3.2   1   


itcl3.1:

libitcl3.1  1   
libitk3.1   1   


jack-audio-connection-kit:
==
libjack 0 libjack0 (= ${Source-Version})


kdepim:
===
libakregatorprivate 0
libkmailprivate 0
libknodecommon 0


keynote:

libkeynote 0 libkeynote0 (>> 2.3-0)


kmymoney2-plugin-aqbanking:
===
libkmm_mymoney 0 kmymoney2 (>= 0.9.2)
libkmm_plugin 0 kmymoney2 (>= 0.9.2)


lam:

liblam 4 liblam4
liblam++ 4 liblam4
liblamio 4 liblam4


lapack:
===
liblapack 3gf liblapack3gf | liblapack.so.3gf | libatlas3gf-base


leptonlib:
==
libleptonlib 1.36 leptonlib (>> 1.36-0), leptonlib (<< 1.36-99)


libcddb:

liblibcddb 1.0.2 libcddb (>> 1.0.2-0)


libcompface:

[Fwd: Considering package removal [glademm]]

[Christoph Egger]

Hi all!

  As suggested by KiBi I am forwarding this here to get your opinion
about removing this package.

Thanks

  Christoph

 Original-Nachricht 
Betreff: Considering package removal [glademm]
Weitersenden-Datum: Sun, 21 Dec 2008 20:23:20 + (UTC)
Weitersenden-Von: debian-ment...@lists.debian.org
Datum: Sun, 21 Dec 2008 20:52:29 +0100
Von: Christoph Egger 
An: debian-ment...@lists.debian.org
Newsgruppen: gmane.linux.debian.devel.mentors

  As I have never requested removal of an package I'm asking here for
some opinions to make sure my thoughts are reasonable. Any comments are
welcome!

=3D=3D=3D=3D=3D
Some Data:

 * Popcon inst: 359
 * Open Bugs: 6 <=3D normal
 * Last upstream release: May 2005
 * priority: optional
 * Section: devel

=3D=3D=3D=3D=3D

  I'm currently maintaining glademm, which is an sourcecode generator
producing C++ sources from glade files. While doing so I'm currently
going through the pieces upstream left unreleased. However I'm in
serious doubt this is worth the trouble.

  First of all, glademm is unmaintained upstream for years. While this
would not be an reason for removal on it's own I see it as an hint.
Furthermore the way glademm works is deprecated (as is glade as an code
generator) and should be replaced by libglade(mm). It is impossible in
debian to create C Sources from glade (C being the =C2=ABoriginal=C2=BB G=
TK
language) but it's still possible to create C++ Sources.

  Well glademm's functionality is quite limited, too. Accoring to actual
code =C2=ABgnome2 support is still experimental=C2=BB but in debian it is=
 actually
broken (#126054 for example) (it requires libbonobomm which is not
available). Doing some simple gtk2 stuff however works (with some
limitations, see bugpage).

  One of the reasons to go backporting some more recent commits was some
bug fixed there (see #335696). But while doing so I realised nearly all
test in the testsuit currently fail. While I will certainly be able to
at least fix the now present gettext problem it will cause considerable
work.

Regards

  Christoph Egger






-- 
/"\  ASCII Ribbon : GPG-Key ID: 0x0372275D
\ /Campaign   :
 X   against HTML : Working for Debian
/ \   in eMails   : http://www.debian.org/



signature.asc
Description: OpenPGP digital signature

Re: Monitoring debian/shlibs.local files?

[Loïc Minier]

On Sun, Dec 21, 2008, Cyril Brulebois wrote:
> (generated by the Makefile in ~kibi/shlibs-check.git, on gluck.)

 attached dd-list with uploaders

 sed -n '/^#/!s/:$//p' mapping.list | dd-list -i -u

-- 
Loïc Minier
Guenter Geiger (Debian/GNU) 
   jack-audio-connection-kit (U)
   rezound

Jacek Śliwerski (rzyjontko) 
   elmo

Bill Allombert 
   libjpeg6b

Kumar Appaiah 
   festival (U)

Hakan Ardo 
   libcompface

maximilian attems 
   usplash

Mirco Bauer 
   mono (U)

Christian Bayle 
   gatos

Christoph Berg 
   xar

Bastian Blank 
   cdebconf (U)

Jérémy Bobbio 
   cdebconf (U)

Jeff Breidenbach 
   leptonlib

Ludovic Brenta 
   monotone (U)

Marc 'HE' Brockschmidt 
   gail (U)

Phil Brooke 
   topal

Mark Brown 
   nis
   nis (U)

Thomas Bushnell, BSG 
   gnucash

Martin Buck 
   xview

Marco Cabizza 
   control-center

Ondrej Certik 
   blas (U)
   lapack (U)

Joost Yervante Damad 
   glew

Debian CLI Applications Team 
   tangerine

Debian GIS Project 
   proj

Debian GNOME Maintainers 
   control-center (U)
   gail
   librsvg (U)

Debian Install System Team 
   cdebconf

Debian Mono Group 
   mono

Debian Multimedia Team 
   jack-audio-connection-kit

Debian OpenMPI Maintainers 
   openmpi

Debian Qt/KDE Maintainers 
   kdepim

Debian Scientific Computing Team 
   blas
   lapack

Debian Tcl/Tk Packagers 
   itcl3
   itcl3.1

Debian VoIP Team 
   iaxclient
   libosip2
   ser

Matthieu Delahaye 
   libunwind

Yann Dirson 
   tulip

Sebastian Dröge 
   control-center (U)
   gail (U)
   librsvg (U)
   mono (U)
   tangerine (U)

Dirk Eddelbuettel 
   openmpi (U)
   r-base
   r-base-core-ra
   rmysql

Robert S. Edmonds 
   adns

Mark W. Eichin 
   owl

Free Ekanayaka 
   jack-audio-connection-kit (U)

Carey Evans 
   tn5250

ExpPsy Maintainers 
   pyode

Arnaud Fontaine 
   tuxonice-userui

Charles Fry 
   courierpassd
   courierpasswd
   courieruserinfo

Peter S Galbraith 
   proj (U)

RISKO Gergely 
   freecell-solver
   mcrypt

Sergei Golovan 
   itcl3 (U)
   itcl3.1 (U)
   tcl8.3 (U)
   tcl8.4 (U)
   tcl8.5 (U)
   tk8.3 (U)
   tk8.4 (U)
   tk8.5 (U)

Debian QA Group 
   ftplib
   metamail
   prestimel
   saods9
   smtpguard
   waproamd
   wsoundserver

Yaroslav Halchenko 
   pyode (U)

Brandon Hale 
   tangerine (U)

Michael Hanke 
   pyode (U)

Chris Hanson 
   uudeview

Sam Hartman 
   barnowl

Paul Hedderly 
   vstream-client

HJ Heins 
   iceape (U)

Joey Hess 
   cdebconf (U)

Mike Hommey 
   iceape (U)

David Härdeman 
   usplash (U)

Jan Janak 
   ser (U)

Matthew Johnson 
   lirc (U)

LaMont Jones 
   util-linux
   xdelta

Muammar El Khatib 
   scalapack

Tatsuya Kinoshita 
   eb

Michael Koch 
   sdl-image1.2

Kilian Krause 
   iaxclient (U)
   libosip2 (U)
   ser (U)

Anand Kumria 
   libosip2 (U)

Mario Lang 
   gail (U)

Sylvestre Ledru 
   lapack (U)
   openmpi (U)

Micha Lenk 
   kmymoney2-plugin-aqbanking

Richard Levitte 
   monotone (U)

Faidon Liambotis 
   iaxclient (U)

Anselm Lingnau 
   tcl8.3 (U)
   tcl8.4 (U)
   tk8.3 (U)
   tk8.4 (U)

Stefan Lippers-Hollmann 
   lirc (U)

lirc Maintainer Team 
   lirc

Ana Beatriz Guerrero Lopez 
   kdepim (U)

Francesco Paolo Lovergine 
   proj (U)

Sven Luther 
   gnome-randr-applet

Marcelo E. Magallon 
   glew (U)
   mesa-legacy

Mikael Magnusson 
   iaxclient (U)

Camm Maguire 
   blas (U)
   lam
   lapack (U)
   xmpi

Maintainers of Mozilla-related packages 

   iceape

Santiago Garcia Mantinan 
   swfdec-mozilla

Patrick Matthäi 
   geoip

Alastair McKinstry 
   console-tools
   slang2

Remco van de Meent 
   gsnmp
   libsmi

A Mennucc1 
   libppd

Samuel Mimram 
   sdl-ttf2.0

Loic Minier 
   control-center (U)
   gail (U)
   librsvg (U)

Jim Mintha 
   slang2 (U)

Kartik Mistry 
   festival

Emilio Pozuelo Monfort 
   librsvg (U)

Debian Maintainers for Monotone 
   monotone

Josselin Mouette 
   control-center (U)
   librsvg

Ramakrishnan Muthukrishnan 
   ygl (U)

Sven Müller 
   lirc (U)

Mark Nevill 
   libxdg-basedir

Jaakko Niemi 
   sfs

Sam Hocevar (Debian packages) 
   sdl-ttf2.0 (U)

Barak A. Pearlmutter 
   adolc

Andrei Pelinescu-Onciul 
   ser (U)

Ari Pollak 
   pidgin

Frans Pop 
   cdebconf (U)

Manuel Prinz 
   openmpi (U)

Mark Purcell 
   iaxclient (U)
   libosip2 (U)
   ser (U)

Prabhu Ramachandran 
   ygl

Petter Reinholdtsen 
   usplash (U)

Andreas Rottmann 
   guile-gnome-platform

Miriam Ruiz 
   libxdg-basedir (U)

Alexander Sack 
   iceape (U)

Anibal Monsalve Salazar 
   pcp (U)
   xfsdump (U)

Darren Salt 
   xine-lib (U)

Otavio Salvador 
   usplash (U)

Niv Sardi 
   xfsdump (U)

Nathan Scott 
   pcp
   xfsdump

Jo Shields 
   mono (U)

Raúl Sánchez Siles 
   kdepim (U)

Miquel van Smoorenburg 
   nis (U)

Roger So 
   im-sdk
   im-sdk (U)

Jose Carlos Garcia Sogo 
   tangerine (U)

Clément Stenac 
   libcddb

Al Stone 
   libunwind (U)

Tatsuki Sugiura 
   libfcgi

Akira TAGOH 
   im-sdk (U)

NOKUBI Takatsugu 
   namazu2

Reinhard Tartler 
   xine-lib

Michael Tautschnig 
   diagnostics

Tcl/Tk Debian 

Re: Self-assessment of the quality of the maintenance work

[Russ Allbery]

Raphael Hertzog  writes:

> Agreed. I'm not sure what's the best way to handle this.
>
> Maybe the form should make it easy to give the same answers to all
> packages that are maintained by a given team ? We could use easily
> identify the team by finding out an email that matches @lists\. in
> either the Maintainer: field or the Uploaders: field.

That would do it for me.  That's a good idea.  I think if I could set a
default answer for all packages in a given team and then go back and tweak
the ones that are special for some reason, it would make that case
relatively fast.

I'm not sure that lack of response should be taken as a definitive
indication of anything, but I'm not sure that it would need to be to still
gather useful information from this sort of thing.

I'd be happy to fill out such a survey every six months or so, and I'd be
curious to see the results.

Maybe, similar to low-threshold-NMU, it would work best if it started as
an opt-in system?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Self-assessment of the quality of the maintenance work

[gregor herrmann]

On Sun, 21 Dec 2008 11:28:17 +0100, Raphael Hertzog wrote:

> > That's going to be a lot of fairly mindless paperwork for someone who's
> > the member of a large, active team with a lot of packages.
> Agreed. I'm not sure what's the best way to handle this.
> Maybe the form should make it easy to give the same answers to all
> packages that are maintained by a given team ? 

An option for setting values for all packages would be nice (and
maybe not only for team-maintained packages).

> Another answer might be to hide all packages which are fine under the
> current norms (to be defined: no bugs (or less than X bugs), no lintian
> errors, ???) and use some predefined answers in those cases. The form would 
> focus on packages with problems (or that are getting worse over time).

I think hiding kind of defeats the purpose of the idea :)
But setting sane default values based on some metrics would make it
easier indeed.

Cheers,
gregor 
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Paul Simon: The Obvious Child


signature.asc
Description: Digital signature

Re: Self-assessment of the quality of the maintenance work

[Mark Brown]

On Sun, Dec 21, 2008 at 11:16:28AM +0100, Raphael Hertzog wrote:

> The best results are achieved if everyone participates so I'd rather find
> ways to make it painless for everybody first. But knowing how diverse the
> opinions are, we will probably have to do something like this.

There's no way this is going to be painless for everyone: you're going
to be sending mails that make work for people that require them to do
something that they wouldn't otherwise have to do.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Self-assessment of the quality of the maintenance work

[Mark Brown]

On Sat, Dec 20, 2008 at 06:19:26PM +0100, Raphael Hertzog wrote:

> The collation of all those data will give us a better view on the
> maintenance status of each package and it could be displayed on the PTS.
> We could also use those info to direct new contributors to help in
> existing packages instead of packaging new stuff.

> What do you think of the idea ?

I'm not sure that the e-mail bit of this really adds anything - the
information reported is only going to be as good as the people filling
it in make it and there's little motiviation to make much effort with
the data.  Something that used existing metrics to try to determine if
the package was actively maintained before sending the mail might be
more useful there and would avoid making work for people who are clearly
active.

The web application side of it does sound like a good idea, though: the
existing WNPP has some issues arising from the use of the BTS as the
back end (like making sure e-mails get seen by the right people, for
example).

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#509416: PTS & DDPO: generic way to add and remove QA reports to PTS pages

[Paul Wise]

Package: qa.debian.org
Severity: wishlist

I think a generic way to allow people (inc those not in the QA group) to
add QA report links to each package with issues that QA report covers.

I think a mail bot is the way to implement this, some ideas on that:

To: pts-rep...@qa.d.o
new broken-shlibs-local http://people.debian.org/~kibi/broken-shlibs-local.yaml
remove foopkg from broken-shlibs-local
add foopkg to broken-shlibs-local
sync broken-shlibs-local
delete broken-shlibs-local
thanks

The YAML (or XML) file could look something like this:

title: Broken shlibs.local
about-url: http://people.debian.org/~kibi/broken-shlibs-local.html
update-frequency: weekly
contact: k...@debian.org
packages:
- name: foo
  url: http://people.debian.org/~kibi/broken-shlibs-local/f/foo.html
  title: 5 issues

The mail bot could regularly mail the contact address whenever the PTS'
list of packages for that report are out of sync with the list of
package names in the YAML file (to motivate them to fix the report).

The PTS could put "Broken shlibs.local (5 issues)" in the right column
in the other links section.

DDPO could use the same data and add a column containing just the name
of each report the package is listed in.

Inspired by yet another dd-list report about another QA issue:

http://lists.debian.org/debian-qa/2008/12/msg00063.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part