Re: Making better use of multiple maintainers
On Wed, Sep 05, 2001 at 01:02:34AM +0200, Martin Michlmayr wrote: However, I'm not sure I agree that a backup is totally useless in the case of celestia. What happens if you're on vacation, woody is released tomorrow and a RC bug is filed on celestia today and noone cares to upload a fixed package? If no one cares to spend a few minutes to upload a fixed package, who is interested enough to become a maintainer (even backup) of the package? If no one's interested enough to upload a fixed package, it's probably not going to be a big deal if it doesn't get released with woody. Similarly, if you were really busy for a while, your backup could do uploads so the users don't have to wait for bug fixes too long. It could be just as easy for someone to pick up a backup maintainer at that point, though. One (partial) solution is to encourage developers to offer to make a NMU rather than just let bugs set. -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored. - Joseph_Greg
Re: Making better use of multiple maintainers
On Wed, Sep 05, 2001 at 01:02:34AM +0200, Martin Michlmayr wrote:
useless in the case of celestia. What happens if you're on vacation,
woody is released tomorrow and a RC bug is filed on celestia today and
noone cares to upload a fixed package? Similarly, if you were really
busy for a while, your backup could do uploads so the users don't have
to wait for bug fixes too long.
I'd guess that it {could be|is} often the case that whilst only one
person knows the package well enough to take on major upgrades, development
etc., several know it well enough to be able to make bug fixes in the
manner that the maintainer would wish.
What I'm trying to say is that a backup makes sense in virtually all
cases, even in the case of smaller packages. Bigger packages certainly
benefit to a higher degree, but I think it makes sense for smaller
packages, too.
Absolutely.
--
Nick Phillips -- [EMAIL PROTECTED]
A long-forgotten loved one will appear soon.
Buy the negatives at any price.
Re: Making better use of multiple maintainers
Le Tue, Sep 04, 2001 at 12:30:12PM -0400, Joey Hess écrivait: I would like to see this oft-requested feature, but in the meantime there is nothing to prevent you as a backup maintainer from seeing every bug for every package you backup maintain. debian-bugs-dist + procmail. Trivial. Of course, but not many people use this ... trivial but still too complicated. Too expensive for people behind modem... of course they could subscribe via their debian.org [1] address and use procmail on the Debian machines ... but still it requires many efforts for a very little gain. Cheers, [1] That is only possible for actual developers and not future developer or simply contributor ... and also not possible for the upstream author (if he's interested in Debian). -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com
Re: Making better use of multiple maintainers
Le Sun, Sep 02, 2001 at 07:55:43PM +0200, Martin Michlmayr écrivait: I think we should try to implement that scheme at least for packages in base and standard... but why not go ahead and try to do it for all packages? Yes, this is a long term thing to do ... it will be quite a logical step once we have everything, there's the support for it in katie and dpkg (at least there'll be shortly). The only thing that is missing and that is *required* is the integration with the BTS. There's several things that have to be done : - be able to subscribe other people to a package bug list (in this case the people listed in the Uploaders field), there should be some automation here, otherwise beeing in the Uploader field won't change anything as the backup maintainer won't know of any bug - when doing a per maintainer lookup (http://bugs.debian.org/[EMAIL PROTECTED] for example) the page should also list the bugs on package where I am an Uploader, probably separated from my very own packages, or maybe just provide a BIG link to the page listing those ... - the Uploader should also be listed on per package page ... so that people may know who to contact when the main maintainer doesn't respond - then we need to update the package@packages.debian.org alias to list all maintainer (main and backup). would get more attention and more bugs fixed. The BTS allows more than one person to get bug reports for a specific package (through an overwrite file) and in the future it will be possible to subscribe to individual bugs. I'm eagerly waiting for this one ... :) as long as the subscription is not only per bug-report but also per source-package and per binary-package. Debian is growing quite dramatically in size but I'd love to see more manpower devoted to existing packages instead of (or in addition to) new packages. /me too Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com
Re: Making better use of multiple maintainers
Raphael Hertzog wrote: There's several things that have to be done : - be able to subscribe other people to a package bug list (in this case the people listed in the Uploaders field), there should be some automation here, otherwise beeing in the Uploader field won't change anything as the backup maintainer won't know of any bug I would like to see this oft-requested feature, but in the meantime there is nothing to prevent you as a backup maintainer from seeing every bug for every package you backup maintain. debian-bugs-dist + procmail. Trivial. -- see shy jo, who just sees every bug, period, and uses scoring on some package names
Re: Making better use of multiple maintainers
* Marcelo E. Magallon [EMAIL PROTECTED] [20010902 21:26]: * wmaker. It's not a complex package, but it operates under several * celestia. Simple. Very limited scope. Not many configuration options. Would I like to find a co-maintainer for wmaker? Yes. Celestia? No. My criteria for considering co-maintainership is simple: Can I cover all the possible ways of using this package myself? I agree with you that it is more important in the case of wmaker where more than one developer can work on the package without much communication. However, I'm not sure I agree that a backup is totally useless in the case of celestia. What happens if you're on vacation, woody is released tomorrow and a RC bug is filed on celestia today and noone cares to upload a fixed package? Similarly, if you were really busy for a while, your backup could do uploads so the users don't have to wait for bug fixes too long. What I'm trying to say is that a backup makes sense in virtually all cases, even in the case of smaller packages. Bigger packages certainly benefit to a higher degree, but I think it makes sense for smaller packages, too. -- Martin Michlmayr [EMAIL PROTECTED]
Re: Making better use of multiple maintainers
I think it's a great idea. I also note that quite a few base packages already have multiple or backup maintainers -- dpkg, boot-floppies, and tasksel come to mind. I've also been unofficial backup maintainer for some other packages in the past and I doubt I'm alone. Formalizing this and using the Uploaders field and everything seems like a natural progression. (So who would like to be a backup maintainer for debconf? ;-) I'm having a hard time getting it to work though. I tried Uploaders with dpkg 1.9.17 and no go: dpkg-gencontrol: warning: unknown information field Uploaders in input data in general section of control info file Also, do you have to redundantly list the package maintainer in the uploaders field if it's present, or do you just list any other maintainers? Separated by commas? This thing needs some documentation. -- see shy jo
Re: Making better use of multiple maintainers
Joey Hess [EMAIL PROTECTED] writes: I think it's a great idea. I also note that quite a few base packages already have multiple or backup maintainers -- dpkg, boot-floppies, and tasksel come to mind. I've also been unofficial backup maintainer for some other packages in the past and I doubt I'm alone. Formalizing this and using the Uploaders field and everything seems like a natural progression. I second that. In my company is another Debian developer who has (hopefully) sufficient knowledge about the packages and has access to the diffs/packaging files in our CVS and the build script, so it would be a good idea to join as backup maintainer. Ciao Racke -- Racke happily hacks Interchange and maintains Debian packages like Courier. For projects and other business stuff please refer to COBOLT NetServices (URL: http://www.cobolt.net; Email: [EMAIL PROTECTED]; Phone: 0041-1-3884400)
Re: Making better use of multiple maintainers
On Sun, Sep 02, 2001 at 07:55:43PM +0200, Martin Michlmayr wrote: During the base freeze preparations in the last few weeks, a problem Debian has always had became apparent again. Since Debian is a distributed, volunteer run project it is hard to tell whether a maintainer is doing Debian work at the moment. In the freeze, it is often crucial to get a bug fixed within a very short period of time. If the maintainer doesn't respond to e-mail immediately, you can either wait or make an NMU. The former is problematic since it might delay the freeze and the latter might break the package, which in turn would cause a delay (Of course NMUs don't always break the package but the likelihood of breaking a package is higher if you don't know the package well). A feature has recently been implemented in dpkg/katie which could solve this problem (along with a couple of others) if deployed properly. In Debian, a package usually has one maintainer. When someone other than the maintainer makes a source upload, katie recognizes the upload as an NMU and tags the bugs as fixed instead of closing them. Since some packages have multiple maintainers, an Uploaders field (in debian/control) has been introduced in dpkg 1.9.13 (see #101815) -- katie now also checks this field in order to determine if the upload is an NMU. What I'm basically proposing is that it would be nice if packages had a backup maintainer or two listed in the Uploaders field. The maintainer could ask someone with whom he works together well and whom he trusts if he wants to co-maintain the package. The maintainer would still act as the package's official maintainer, but the other one can act as a backup when the main maintainer is busy or on vacation. I think we should try to implement that scheme at least for packages in base and standard... but why not go ahead and try to do it for all packages? Seconded. -- Eric VAN BUGGENHAUT Oh My God! They killed init! You Bastards! --from a /. post \_|_/ Andago \/ \/ Av. Santa Engracia, 54 a n d a g o |--E-28010 Madrid - tfno:+34(91)2041100 /\___/\ http://www.andago.com / | \ Innovando en Internet [EMAIL PROTECTED]
Re: Making better use of multiple maintainers
Joey Hess [EMAIL PROTECTED] writes: I'm having a hard time getting it to work though. I tried Uploaders with dpkg 1.9.17 and no go: dpkg-gencontrol: warning: unknown information field Uploaders in input data in general section of control info file It needs to be in the source section of the control file, like the Maintainer field. Also, do you have to redundantly list the package maintainer in the uploaders field if it's present, or do you just list any other maintainers? The latter. Separated by commas? Yes. -- James
Re: Making better use of multiple maintainers
James Troup wrote: Joey Hess [EMAIL PROTECTED] writes: I'm having a hard time getting it to work though. I tried Uploaders with dpkg 1.9.17 and no go: dpkg-gencontrol: warning: unknown information field Uploaders in input data in general section of control info file It needs to be in the source section of the control file, like the Maintainer field. That's what it means by general section as far as I can tell. Source: tasksel Section: base Priority: optional Maintainer: Randolph Chung [EMAIL PROTECTED] Uploaders: Joey Hess [EMAIL PROTECTED] Standards-Version: 3.5.6.0 That's how I tried it, no go. dpkg-gencontrol does not contain the word '[Uu]ploaders' on my system either. -- see shy jo
Re: Making better use of multiple maintainers
Joey Hess [EMAIL PROTECTED] writes: That's how I tried it, no go. dpkg-gencontrol does not contain the word '[Uu]ploaders' on my system either. Oh, right, yah, okay; it appears it was only dpkg-source that was patched. The dpkg-gencontrol is just a warning though, the Uploaders field still appears in the .dsc (for me at least) and that's what's matters. The spurious warning thing should probably be fixed (or at least reported) though; I'll do that now. -- James
Re: Making better use of multiple maintainers
Martin Michlmayr [EMAIL PROTECTED] writes: - Bugs could get fixed sooner since more people are working on the package. This would help us meeting our release goals. The Mythical Man Month, of which Debian is exemplary[0]. Given enough eyes, all bugs are shallow, of which Debian is also exemplary, is a another, prettier, way of saying men and months are interchangeable commodities only when a task can be partitioned among many workers *with no communication among them*. It doesn't mean throw more people at a problem and it will get solved faster. Your idea is practicable iff the group of maintainers actually communicate with each other, that is, the package is actually jointly maintained. Let me take two of my own packages as an example: * wmaker. It's not a complex package, but it operates under several different conditions (or enviroments) which are different enough from each other that makes it imposible for me to gain expertise in all of them (IOW, I don't use wmaker with GNOME, and it's very time consuming for me to try to figure out ways of reproducing bugs under those conditions, given the *absolutely* *wonderful* and *marvelous* documentation GNOME and its packages have) * celestia. Simple. Very limited scope. Not many configuration options. Would I like to find a co-maintainer for wmaker? Yes. Celestia? No. My criteria for considering co-maintainership is simple: Can I cover all the possible ways of using this package myself? [0] We never finished that conversation at Linux Tag. -- Marcelo | This signature was automatically generated with [EMAIL PROTECTED] | Signify v1.07. For this and other cool products, | check out http://www.debian.org/
Re: Making better use of multiple maintainers
How are things going to get better if new things like this aren't tried? It'll certainly knock out some issues in sponsorship and NM... If your only objections are those of the improbability of getting it to work, let Martin run with it and find out for hisself. On Sun, 2 Sep 2001, Marcelo E. Magallon wrote: Martin Michlmayr [EMAIL PROTECTED] writes: - Bugs could get fixed sooner since more people are working on the package. This would help us meeting our release goals. The Mythical Man Month, of which Debian is exemplary[0]. Given enough eyes, all bugs are shallow, of which Debian is also exemplary, is a another, prettier, way of saying men and months are interchangeable commodities only when a task can be partitioned among many workers *with no communication among them*. It doesn't mean throw more people at a problem and it will get solved faster. Your idea is practicable iff the group of maintainers actually communicate with each other, that is, the package is actually jointly maintained. Let me take two of my own packages as an example: * wmaker. It's not a complex package, but it operates under several different conditions (or enviroments) which are different enough from each other that makes it imposible for me to gain expertise in all of them (IOW, I don't use wmaker with GNOME, and it's very time consuming for me to try to figure out ways of reproducing bugs under those conditions, given the *absolutely* *wonderful* and *marvelous* documentation GNOME and its packages have) * celestia. Simple. Very limited scope. Not many configuration options. Would I like to find a co-maintainer for wmaker? Yes. Celestia? No. My criteria for considering co-maintainership is simple: Can I cover all the possible ways of using this package myself? [0] We never finished that conversation at Linux Tag. -- EMACS == Eight Megabytes And Constantly Swapping Who is John Galt? [EMAIL PROTECTED], that's who!
Re: Making better use of multiple maintainers
[ your Mail-Followup-To is still leaving the list out ] John Galt [EMAIL PROTECTED] writes: How are things going to get better if new things like this aren't tried? It'll certainly knock out some issues in sponsorship and NM... If your only objections are those of the improbability of getting it to work, let Martin run with it and find out for hisself. Martin's mail was much longer than the tiny little bit which I replied to. I actually replied only to the assertion than putting more people behind one package gets bugs fixed faster because there's more people behind it, and I was by no means bashing his idea. I actually provided one example where it could make sense. I ought to listen to Zinsser and use shorter words, I obviously failed to get an idea across. -- Marcelo | This signature was automatically generated with [EMAIL PROTECTED] | Signify v1.07. For this and other cool products, | check out http://www.debian.org/
Re: Making better use of multiple maintainers
On Sun, Sep 02, 2001 at 10:57:06PM +0200, Marcelo E. Magallon wrote: I ought to listen to Zinsser and use shorter words Only with Galt. -- G. Branden Robinson|If you wish to strive for peace of Debian GNU/Linux |soul, then believe; if you wish to [EMAIL PROTECTED] |be a devotee of truth, then http://people.debian.org/~branden/ |inquire. -- Friedrich Nietzsche pgpYBbW3MuGmv.pgp Description: PGP signature
