Re: Dogme05: Team Maintenance
* Andreas Barth: Please: remember that we all tend sometimes to say too harsh things in mail (or rather, we forget that this is not some chit-chat, and everything is printed and archived), and also that it's way too easy to over-interpret someone else, as we just have the text, and not the emotional suroundings (tone, face expressions, ...). And from time to time, I can really understand fellow developers who resort to threats in a desperate attempt to move things forward. 8-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
Quoting Florian Weimer ([EMAIL PROTECTED]): Please keep in mind that responsible maintainers do not depend on unmaintained services such as alioth.debian.org. If you must use it, make sure that you make periodic copies of archives stored on costa. Well, I'm afraid that I'm not a responsible maintainer, then:-) So is the d-i team, the testing security team and so on. Maybe alioth maintenance does not fit your own admin quality reference system. Then, I see a few solutions to this: -contribute to alioth system administration -make constructive suggestions (constructive suggestions are argumented suggestions and sometimes accept that people do not agree with what you suggest) -do not use it -build a concurrent collaborative development environment and convince people that it's better than alioth As far as I know, Alioth maintenance is handled by the relevant people on their free time, as a volunteer work (just like all work we do in this project). Thus they deserve some respect for the time they invest in it. *Even* if you do not agree with their technical choices or method of work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
* Christian Perrier: Well, I'm afraid that I'm not a responsible maintainer, then:-) But you do keep backups, I hope. Maybe alioth maintenance does not fit your own admin quality reference system. I'm not the only one who is complaining. Then, I see a few solutions to this: -contribute to alioth system administration This isn't possible, apparently, see Raphaël's message [EMAIL PROTECTED] and its follow-ups. Even DSA doesn't contribute to system maintenance. -make constructive suggestions (constructive suggestions are argumented suggestions and sometimes accept that people do not agree with what you suggest) I made a suggestion which was trivial to implement and did fix a real problem. Check the mail archives to see how long it took until it was acted upon. As far as I know, Alioth maintenance is handled by the relevant people on their free time, as a volunteer work (just like all work we do in this project). I've been privately told that an alioth admin demands hardware in compensation for his Debian-related work, effectively blackmailing the DPL. I don't know if this is true, I hope it's not.
Re: Dogme05: Team Maintenance
On Sat, 2005-08-27 at 10:06 +0200, Florian Weimer wrote: I've been privately told that an alioth admin demands hardware in compensation for his Debian-related work, effectively blackmailing the DPL. I don't know if this is true, I hope it's not. Making grave accusations based on rumours is very destructive behaviour. Either you make claims you can back up with references, or you keep them for yourself. This doesn't do any good for anyone. Thanks Thijs signature.asc Description: This is a digitally signed message part
Re: Dogme05: Team Maintenance
* Thijs Kinkhorst: On Sat, 2005-08-27 at 10:06 +0200, Florian Weimer wrote: I've been privately told that an alioth admin demands hardware in compensation for his Debian-related work, effectively blackmailing the DPL. I don't know if this is true, I hope it's not. Making grave accusations based on rumours is very destructive behaviour. Either you make claims you can back up with references, or you keep them for yourself. This doesn't do any good for anyone. I can't quote from private mail. I've checked the claim with someone who knows the parties involved better than I, and he wasn't surprised at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sat, 2005-08-27 at 10:16 +0200, Florian Weimer wrote: * Thijs Kinkhorst: On Sat, 2005-08-27 at 10:06 +0200, Florian Weimer wrote: I've been privately told that an alioth admin demands hardware in compensation for his Debian-related work, effectively blackmailing the DPL. I don't know if this is true, I hope it's not. Making grave accusations based on rumours is very destructive behaviour. Either you make claims you can back up with references, or you keep them for yourself. This doesn't do any good for anyone. I can't quote from private mail. I've checked the claim with someone who knows the parties involved better than I, and he wasn't surprised at all. Doesn't change my point: if you can't quote from that mail, don't make unverifiable claims in a public forum. Either continue your quest in private where you can back up your claim, or forget about it as long as its not even remotely provable. Making unverifiable grave accusations in public is never good, whatever the reasons that references are missing. Thijs signature.asc Description: This is a digitally signed message part
Re: Dogme05: Team Maintenance
* Thijs Kinkhorst: unverifiable grave accusations It's not unverifiable (you can ask the DPL if you wish, or the admins involved), and it's not a very grave accusation, either. See it as an encouragement to make backups of your data on Debian's machines. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sat, 2005-08-27 at 10:34 +0200, Florian Weimer wrote: * Thijs Kinkhorst: unverifiable grave accusations It's not unverifiable (you can ask the DPL if you wish, or the admins involved), and it's not a very grave accusation, either. See it as an encouragement to make backups of your data on Debian's machines. blackmailing the DPL is not a grave accusation? You must be kidding. If you really think this should be treated in public, find proof for it: people who are willing to back up your claim in public, not just in private mail. If you can't find anyone who wants this, bad luck, stop it. Thijs signature.asc Description: This is a digitally signed message part
Re: Dogme05: Team Maintenance
Hi, (that I answer to this mail is just pure Chance - it's meant at you both, and I might have answered to another mail equally well :) * Thijs Kinkhorst ([EMAIL PROTECTED]) [050827 10:46]: On Sat, 2005-08-27 at 10:34 +0200, Florian Weimer wrote: * Thijs Kinkhorst: unverifiable grave accusations It's not unverifiable (you can ask the DPL if you wish, or the admins involved), and it's not a very grave accusation, either. See it as an encouragement to make backups of your data on Debian's machines. blackmailing the DPL is not a grave accusation? You must be kidding. Please: remember that we all tend sometimes to say too harsh things in mail (or rather, we forget that this is not some chit-chat, and everything is printed and archived), and also that it's way too easy to over-interpret someone else, as we just have the text, and not the emotional suroundings (tone, face expressions, ...). So, please let's keep the level down. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sat, Aug 27, 2005 at 10:16:58AM +0200, Florian Weimer wrote: * Thijs Kinkhorst: On Sat, 2005-08-27 at 10:06 +0200, Florian Weimer wrote: I've been privately told that an alioth admin demands hardware in compensation for his Debian-related work, effectively blackmailing the DPL. I don't know if this is true, I hope it's not. Making grave accusations based on rumours is very destructive behaviour. Either you make claims you can back up with references, or you keep them for yourself. This doesn't do any good for anyone. I can't quote from private mail. If you can't quote from private mail, then don't mention it. Please. I've checked the claim with someone who knows the parties involved better than I, and he wasn't surprised at all. I've been privately told that you've been seen doing stuff with a duck. I don't know if this is true, I hope it's not. I've checked the claim with someone who knows you better than I do, and he wasn't surprised at all. (no, this isn't true. But I hope you get my point. Either back up your accusations, or keep them for yourself.) -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
* W. Borgert: A fine way to do this, is by having a pkg- project at alioth.debian.org. Please keep in mind that responsible maintainers do not depend on unmaintained services such as alioth.debian.org. If you must use it, make sure that you make periodic copies of archives stored on costa. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
Florian, Le vendredi 26 août 2005 à 11:20 +0200, Florian Weimer a écrit : Please keep in mind that responsible maintainers do not depend on unmaintained services such as alioth.debian.org. YOU MUST STOP YOUR ANTI-ALIOTH CAMPAIGN ! As an alioth admin, I feel attacked each time I read one of your mail and it's getting incredingly annoying. If you must use it, make sure that you make periodic copies of archives stored on costa. That's a reasonable advice in any case... Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
Scripsit Thaddeus H. Black [EMAIL PROTECTED] Henning Makholm wrote: It is already the case that flatly refusing to give away the package or even allow co-maintenance *should* not happen at all and, if it does happen, *should* not prevent the package from eventually being given to somebody who is willing to keep it properly maintained. I agree that our mechanism for turning those shoulds into dos are not, empirically, always working well. But simply adding by fiat another requirement for the maintainer to flatly refuse to follow is not likely to help solving the underlying problem. We have such a mechanism? I didn't know this. I didn't actually look it up, but even if the only mechanism we have is work it out on the mailing lists and appeal to the DPL / tech-ctte / a GR in case of stuckness, it is still a mechanism, at least for my rhetorical purposes :-) Never having personally encountered a serious problem with an intransigent maintainer, I do not know much about it, but now you make me curious. Sorry to have raised your expectations unwarrantedly. -- Henning Makholm Monarki, er ikke noget materielt ... Borger! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Tue, 16 Aug 2005 15:46:51 +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: I disagree. If the maintainer is doing a good job on his (or her) own, then there is no need at all to take away their packages. How do we find out whether a maintainer is doing his/her job well? For example, are the ifupdown and sysklogd packages well maintained? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Dogme05: Team Maintenance
On Tue, 16 Aug 2005 16:42:47 +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: On Tue, Aug 16, 2005 at 04:20:32PM +0200, Thijs Kinkhorst wrote: You're missing an important case here: the one where the maintainer isn't completely absent, but lacks the time to maintain the package in an optimal manner. Those are excellent reasons to give the package away and/or to start looking for comaintainers. In theory, you are right. In practice, we have more than a couple of packages in that state with the maintainer flatly refusing to give away the package or even allow co-maintenance. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Dogme05: Team Maintenance
Scripsit Marc Haber [EMAIL PROTECTED] On Tue, 16 Aug 2005 16:42:47 +0200, Wouter Verhelst Those are excellent reasons to give the package away and/or to start looking for comaintainers. In theory, you are right. In practice, we have more than a couple of packages in that state with the maintainer flatly refusing to give away the package or even allow co-maintenance. It is already the case that flatly refusing to give away the package or even allow co-maintenance *should* not happen at all and, if it does happen, *should* not prevent the package from eventually being given to somebody who is willing to keep it properly maintained. I agree that our mechanism for turning those shoulds into dos are not, empirically, always working well. But simply adding by fiat another requirement for the maintainer to flatly refuse to follow is not likely to help solving the underlying problem. -- Henning Makholm Hør, hvad er det egentlig der ikke kan blive ved med at gå?
Re: Dogme05: Team Maintenance
On Thu, Aug 18, 2005 at 10:33:53AM +0200, Marc Haber wrote: On Tue, 16 Aug 2005 15:46:51 +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: I disagree. If the maintainer is doing a good job on his (or her) own, then there is no need at all to take away their packages. How do we find out whether a maintainer is doing his/her job well? 'Check if there is consensus that the maintainer is doing his/her job well'. Somehow. Preferably /not/ through GR. Anyway, that was not the point; the point was that the status quo is not so bad that we need to invent yet another bureaucratic procedure that will not likely improve much. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
Henning Makholm wrote: Scripsit Marc Haber [EMAIL PROTECTED] On Tue, 16 Aug 2005 16:42:47 +0200, Wouter Verhelst Those are excellent reasons to give the package away and/or to start looking for comaintainers. In theory, you are right. In practice, we have more than a couple of packages in that state with the maintainer flatly refusing to give away the package or even allow co-maintenance. It is already the case that flatly refusing to give away the package or even allow co-maintenance *should* not happen at all and, if it does happen, *should* not prevent the package from eventually being given to somebody who is willing to keep it properly maintained. I agree that our mechanism for turning those shoulds into dos are not, empirically, always working well. But simply adding by fiat another requirement for the maintainer to flatly refuse to follow is not likely to help solving the underlying problem. We have such a mechanism? I didn't know this. Investigating, one sees some words in Policy 3.3 and Developer's Reference 7.4 on the topic, but the words do not seem to speak of intransigent maintainers, only of inactive ones. Verse 6.1.4 in the Constitution seems arguably to give power to the Technical Committee to do what you suggest, but if so, the power remains theoretical: it is not in practice used. Never having personally encountered a serious problem with an intransigent maintainer, I do not know much about it, but now you make me curious. If there are interesting facts I didn't know hereto about the Project, please elaborate. signature.asc Description: Digital signature
Re: Dogme05: Team Maintenance
Dear Wolfang, * W. Borgert [EMAIL PROTECTED] [050814 16:15]: as a conclusion of many discussions at DebConf5, I propose to maintain all packages by teams. [..] Do you realy think you can enforce teamwork? I don't think so. Either some people will work together as a team or individuals will do it their own way. And I don't think it will be a good idea, to force those individuals to work in a team. Yours sincerely, Alexander -- http://learn.to/quote/ http://www.catb.org/~esr/faqs/smart-questions.html signature.asc Description: Digital signature
Re: Dogme05: Team Maintenance
[Alexander Schmehl] Do you realy think you can enforce teamwork? I don't think so. Either some people will work together as a team or individuals will do it their own way. And I don't think it will be a good idea, to force those individuals to work in a team. I agree. There will always be people unwilling or incapable of working in teams, and some of them will be debian developers. I wounder how many of these decided to join in on this thread. But I believe it is a good idea to remove the most important packages in debian from the single set of hands maintaining them at the moment, if the current maintainer is unwilling to maintain these in a team. They should maintain less important packages or learn how to maintain them in a team. We should strive to increase what I normally call the bus-factor; how many people need to be run over by a bus before the project stops. And for several of the packages in debian, the count is 1 or less. I believe we should at least aim for a factor at two or above, to be able to cope with accidents, burnouts and other issues affecting people from time to time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Tue, Aug 16, 2005 at 02:46:35PM +0200, Petter Reinholdtsen wrote: [Alexander Schmehl] Do you realy think you can enforce teamwork? I don't think so. Either some people will work together as a team or individuals will do it their own way. And I don't think it will be a good idea, to force those individuals to work in a team. I agree. There will always be people unwilling or incapable of working in teams, and some of them will be debian developers. I wounder how many of these decided to join in on this thread. But I believe it is a good idea to remove the most important packages in debian from the single set of hands maintaining them at the moment, if the current maintainer is unwilling to maintain these in a team. I disagree. If the maintainer is doing a good job on his (or her) own, then there is no need at all to take away their packages. [...] We should strive to increase what I normally call the bus-factor; how many people need to be run over by a bus before the project stops. And for several of the packages in debian, the count is 1 or less. That's not true. For several of the packages in Debian, it is true that there will be a problem if their maintainer will be run over by a bus. However, that in no way means the project stops. As the past has taught us, should something like that happen, there will be people willing to take over. It might take a bit longer for the new maintainer to be up to speed as compared to when one member of a team gets run over by a bus, but that doesn't mean the project stops. We should strive to increase the quality in Debian. If some people can produce higher-quality packages by working in a team, then more power to them. If other people can produce higher-quality packages by /not/ working in a team, then there is no reason to force them to work in a team. Don't forget that every bit of teamwork results in some overhead; you have to communicate to your team members what you're doing, and all of your team members have to understand it (which may involve tedious explanations and/or some learning time for your team members). Depending on the complexity of a package and the amount of work required to maintain it, this overhead may just not be worth it. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond signature.asc Description: Digital signature
Re: Dogme05: Team Maintenance
On Tue, 2005-08-16 at 15:46 +0200, Wouter Verhelst wrote: It might take a bit longer for the new maintainer to be up to speed as compared to when one member of a team gets run over by a bus, but that doesn't mean the project stops. Team maintenance is only one way to accomplish the goal of uninterrupted high quality of maintenance for all standard essential packages. The PTS allows for non-maintainers of an important package to watch what's happening without necessarily being directly involved in a formal team. Perhaps we can reduce the time to come up to speed by encouraging non-team-maintained packages to be shadowed by additional developers who can then be called upon to NMU as needed? This would entail watching the bug reports as they come in, trying to figure out what's wrong, contributing additional info and/or patches to the bug reports if appropriate, and checking new releases to see what the maintainer has done and why. I think it's important not to underestimate the possible consequences of it taking a bit longer to come up to speed when a maintainer of an important package suddenly disappears. For some values of a bit, the project could suffer a fair amount through such a loss. I can't readily provide an anecdote for when this ever occurred, but I do have a vivid imagination. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Tue, Aug 16, 2005 at 02:46:35PM +0200, Petter Reinholdtsen wrote: [Alexander Schmehl] Do you realy think you can enforce teamwork? I don't think so. Either some people will work together as a team or individuals will do it their own way. And I don't think it will be a good idea, to force those individuals to work in a team. I agree. There will always be people unwilling or incapable of working in teams, and some of them will be debian developers. I wounder how many of these decided to join in on this thread. But I believe it is a good idea to remove the most important packages in debian from the single set of hands maintaining them at the moment, if the current maintainer is unwilling to maintain these in a team. They should maintain less important packages or learn how to maintain them in a team. OK. Please identify the most important packages in Debian :-) Hint: this is not easy. There would need to be some sort of metric or heuristic for deciding the importance of a package. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpkts7t5F1o9.pgp Description: PGP signature
Re: Dogme05: Team Maintenance
On Tue, Aug 16, 2005 at 10:08:15AM -0400, Roberto C. Sanchez wrote: OK. Please identify the most important packages in Debian :-) Hint: this is not easy. There would need to be some sort of metric or heuristic for deciding the importance of a package. We already have a Priority: field. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Tue, Aug 16, 2005 at 11:03:17AM -0300, Ben Armstrong wrote: On Tue, 2005-08-16 at 15:46 +0200, Wouter Verhelst wrote: It might take a bit longer for the new maintainer to be up to speed as compared to when one member of a team gets run over by a bus, but that doesn't mean the project stops. [...] I think it's important not to underestimate the possible consequences of it taking a bit longer to come up to speed when a maintainer of an important package suddenly disappears. For some values of a bit, the project could suffer a fair amount through such a loss. I can't readily provide an anecdote for when this ever occurred, but I do have a vivid imagination. Exactly. I can't, either; and there have been some takeovers of some pretty serious packages who were maintained by one person in the past. As an example, consider what happened when Joel Klecker died (who was maintaining a package of quite some importance at the time). I'm not saying it's necessarily a bad idea to have team maintenance; on the contrary. But forcing people to maintain packages in teams is, I think, a /very/ bad idea. There are some packages that can easily be maintained by one person alone, even if they're quite important; and forcing a team upon such a package is just a drain on the time of the person who's been maintaining it up to then. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Tue, August 16, 2005 15:46, Wouter Verhelst wrote: We should strive to increase what I normally call the bus-factor; how many people need to be run over by a bus before the project stops. And for several of the packages in debian, the count is 1 or less. That's not true. For several of the packages in Debian, it is true that there will be a problem if their maintainer will be run over by a bus. However, that in no way means the project stops. As the past has taught us, should something like that happen, there will be people willing to take over. You're missing an important case here: the one where the maintainer isn't completely absent, but lacks the time to maintain the package in an optimal manner. There are a lot of valid reasons for this to happen, be it real-life responsibilities or other tasks within Debian, but it hurts the quality of the package. It would not be fair to ditch the maintainer in such a case, but having more than one adds a lot more continuity to the quality of a package. This is especially important for packages that are particulary central to debian, i.e. of high priority. The PTS currently says that you should find some co-maintainers if the package is priority standard or higher; I would like to see that upgraded that to 'must'. The argument that a maintainer is currently doing just fine doesn't hold in my opinion, since being swamped in other areas can happen to anyone, and can happen unexpectedly when it's too late to get a comaintainer. You can of course NMU, but that has its problems, and NMU's tend to be only done for the most pressing issues. A co-maintainer who is familiar with the package and knows what's going on can do a lot more good than different people NMUing. regards, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
Le Mardi 16 Août 2005 16:09, Steinar H. Gunderson a écrit : On Tue, Aug 16, 2005 at 10:08:15AM -0400, Roberto C. Sanchez wrote: OK. Please identify the most important packages in Debian :-) Hint: this is not easy. There would need to be some sort of metric or heuristic for deciding the importance of a package. We already have a Priority: field. And why not also using popularity-contest (eg. if a package is used by more than X users, it should be maintained by a team). -- Florent pgpMiXNubb7sS.pgp Description: PGP signature
Re: Dogme05: Team Maintenance
[Roberto C. Sanchez] OK. Please identify the most important packages in Debian :-) Hint: this is not easy. There would need to be some sort of metric or heuristic for deciding the importance of a package. I do not see the need for a waterproof definition capable of splitting the archive in two, the important and the not so important. We could for example start with the packages in base (aka installed by debootstrap), and add the most commonly installed packages as reported by popularity-contest. I have little doubt that these packages are the most important packages in debian, and that all of them are more important than for example one of my own packages, ipmitool. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Tue, Aug 16, 2005 at 04:20:32PM +0200, Thijs Kinkhorst wrote: On Tue, August 16, 2005 15:46, Wouter Verhelst wrote: We should strive to increase what I normally call the bus-factor; how many people need to be run over by a bus before the project stops. And for several of the packages in debian, the count is 1 or less. That's not true. For several of the packages in Debian, it is true that there will be a problem if their maintainer will be run over by a bus. However, that in no way means the project stops. As the past has taught us, should something like that happen, there will be people willing to take over. You're missing an important case here: the one where the maintainer isn't completely absent, but lacks the time to maintain the package in an optimal manner. Those are excellent reasons to give the package away and/or to start looking for comaintainers. [...] The argument that a maintainer is currently doing just fine doesn't hold in my opinion, since being swamped in other areas can happen to anyone, and can happen unexpectedly when it's too late to get a comaintainer. Uh. I meant to say that there are some packages for which maintenance is so low-volume and so easy that the overhead imposed by team-maintenance is just not worth it. For low-volume, easy-to-maintain packages, it's never too late to go get a comaintainer. Or to give the package away. And I simply don't believe that 'important package' implies 'lots of work to maintain it'. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond signature.asc Description: Digital signature
Re: Dogme05: Team Maintenance
On Tue, 2005-08-16 at 16:42 +0200, Wouter Verhelst wrote: For low-volume, easy-to-maintain packages, it's never too late to go get a comaintainer. Or to give the package away. And I simply don't believe that 'important package' implies 'lots of work to maintain it'. I think what you're saying here is quite reasonable. A simple concrete example might help to make this point. Pick a specific package that meets these criteria and go through the thought exercise of when the maintainer is run over by a bus and the package has no co-maintainer. I think the problem is, many of us, like me, do have vivid imaginations and envision bad things happening when an important package loses its only maintainer because the problem is painted in strokes that are overly broad. Perhaps I was too indirect in my request for anecdotes. I'd like some more specific packages discussed so we can identify where the potential problems lie and focus our energies on those, rather than worrying over all of the corner cases that aren't real problems. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
Hi! * Florent Bayle [EMAIL PROTECTED] [050816 16:20]: And why not also using popularity-contest (eg. if a package is used by more than X users, it should be maintained by a team). And what, if a package maintained by a single person (who is doint a good job) is get's a growing userbase and pops beyong X users? What if the single maintainer is doing a good job, but lacks the ability to work in a team? What do you want to do, do solve the inaccuracy of popcon? Yes, I agree. Important packages should be maintained by a team, by trying to enforce such a policy will IMHO cause more problems than it solves. Yours sincerely, Alexander -- http://learn.to/quote/ http://www.catb.org/~esr/faqs/smart-questions.html signature.asc Description: Digital signature
Re: Dogme05: Team Maintenance
Scripsit Wouter Verhelst [EMAIL PROTECTED] I'm not saying it's necessarily a bad idea to have team maintenance; on the contrary. But forcing people to maintain packages in teams is, I think, a /very/ bad idea. Not to mention that people who sincerely believe they work most efficiently as a one-man team would just start forming pro-forma teams that officially pooled maintenance of their former packages but and internally followed a gentleman's agreement about keeping hands off each other's stuff. What next? A package cannot be uploaded N times in a row by the same team member? -- Henning Makholm Occam was a medieval old fart. The simplest explanation that fits the facts is always, God did it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Tue, Aug 16, 2005 at 02:38:01PM +0200, Alexander Schmehl wrote: Do you realy think you can enforce teamwork? I don't think so. Either some people will work together as a team or individuals will do it their One cannot enforce teamwork. Dogma #10 suggests team meetings in sauna as encouragement for team building. own way. And I don't think it will be a good idea, to force those individuals to work in a team. Debian is a large-scale team. Teamwork is a necessity for all the 1278(?) of us. Not by force, maybe by sauna. Cheers, -- Wolfgang Borgert [EMAIL PROTECTED], http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Tue, Aug 16, 2005 at 09:15:11PM +, W. Borgert wrote: On Tue, Aug 16, 2005 at 02:38:01PM +0200, Alexander Schmehl wrote: Do you realy think you can enforce teamwork? I don't think so. Either some people will work together as a team or individuals will do it their One cannot enforce teamwork. Dogma #10 suggests team meetings in sauna as encouragement for team building. Nobody ever told me that Debian had a sauna for team meetings. Do I need to wait until I am through NM, or can I get access beforehand? Where is it located :-) own way. And I don't think it will be a good idea, to force those individuals to work in a team. Debian is a large-scale team. Teamwork is a necessity for all the 1278(?) of us. Not by force, maybe by sauna. The Debian team is probably much larger than that, since it includes people reporting bugs, providing patches, and generally helping out. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpIYwxNyMqoK.pgp Description: PGP signature
Re: Dogme05: Team Maintenance
On Sun, Aug 14, 2005 at 08:29:47PM -0300, Ben Armstrong wrote: Says who? I maintain some packages like this. Let's say I support 50 to 100 niche users for a given package, but I'm the only developer in the user community who cares to maintain the package in Debian. I maintain the package well, and my users are happy. I would not be at all happy if my package were forced out of Debian because it's not worthwhile. I think that would be a terrible injustice to my users. Some of the things under Dogme05 is certainly exaggeration. Sorry, if people thought I want to propose enforcement of team maintenance policy. However, team maintenance for all essential and standard is worthwhile and not un-realistic. HA-ing. I'm sorry. I don't know what you mean. Sorry, we may have to many abbreviation based verbs already, so I should not invent new ones: HA = high availability. Cheers, -- W. Borgert [EMAIL PROTECTED], http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
W. Borgert [EMAIL PROTECTED] writes: Sorry, if people thought I want to propose enforcement of team maintenance policy. However, team maintenance for all essential and standard is worthwhile and not un-realistic. It's a good idea to discuss it, unless it's been discussed to death already. -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Mon, Aug 15, 2005 at 12:16:24AM -0500, Adam Heath wrote: When a new source gets uploaded, it replaces the previous. If several NMUs occur, each one replaces the former. So, when the real maintainer(s) wake up, they can only see the most recent NMU that took place. Only if each NMU does not build upon the previous _and_ each NMU fails to follow NMU guidelines and submit a bug with the complete NMU diff to the BTS. Which is why we have those guidelines. ^_^ (I'm not saying this doesn't happen, but it's as bad as a broken source upload, give or take.) -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpbzWYRbIUi2.pgp Description: PGP signature
Re: Dogme05: Team Maintenance
On Sun, Aug 14, 2005 at 02:15:43PM +, W. Borgert wrote: Assumptions: III. The responsiveness on bug reports is higher, as more people can react without having to NMU. Adjustments between team members can slow down this, but this is just a matter of agreements inside the team. I do not agree that this is always the case. I think that sometimes, a bug which doesn't look like fun to debug or fix can be passed over in team maintenance situations, as no one person is responsible for the package (oh, someone else in the team will pick this one up...) -- Jon Dowland http://jon.dowland.name/ FD35 0B0A C6DD 5D91 DB7A 83D1 168B 4E71 7032 F238 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Mon, 2005-08-15 at 06:14 +, W. Borgert wrote: Some of the things under Dogme05 is certainly exaggeration. Sorry, if people thought I want to propose enforcement of team maintenance policy. However, team maintenance for all essential and standard is worthwhile and not un-realistic. Well, you did say all packages. If you had talked explicitly only about essential and standard packages, you would have heard no complaints from me. HA-ing. I'm sorry. I don't know what you mean. Sorry, we may have to many abbreviation based verbs already, so I should not invent new ones: HA = high availability. Thanks for the secret TLA decoder ring. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Mon, 15 Aug 2005, Paul TBBle Hampson wrote: On Mon, Aug 15, 2005 at 12:16:24AM -0500, Adam Heath wrote: When a new source gets uploaded, it replaces the previous. If several NMUs occur, each one replaces the former. So, when the real maintainer(s) wake up, they can only see the most recent NMU that took place. Only if each NMU does not build upon the previous _and_ each NMU fails to follow NMU guidelines and submit a bug with the complete NMU diff to the BTS. The bts is the only way this occurrs. Several maintainers now maintain their packages completely within version control. I can see them wanting to have every version ever uploaded as a separate tag/branch(whatever). If an NMU upload does not file a bug, then this becomes problematic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
also sprach W. Borgert [EMAIL PROTECTED] [2005.08.14.1615 +0200]: V. If not at least two maintainers can be found for a particular package, it is not worthwhile to have it in Debian, at least not in a release. experimental is OK. [...] VIII. Packages not maintained by teams are not to go into unstable/testing/stable. No, please. I second your incentive, but I don't think it should be a guideline or best-practice rather than a rule. There is *way* too much overhead and I don't think it warrants the benefits in many/most cases. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! micro$oft windoze is like an air-conditioner: it breaks down if you open a window. signature.asc Description: Digital signature (GPG/PGP)
Re: Dogme05: Team Maintenance
On 10381 March 1977, W. Borgert wrote: as a conclusion of many discussions at DebConf5, I propose to maintain all packages by teams. No, thanks. VI. The advantages of team maintenance outweigh the problem of team maintenance overhead. Not everywhere, no. VII. Team maintainence helps us to collaborate with upstream and derivers. No, why? You can have good connections to them without team-stuff. VIII. Packages not maintained by teams are not to go into unstable/testing/stable. Nope, wrong way. Team maintenance may be nice for many things, but to make it a constraint is bad and works against it. -- bye Joerg Sahneschnitter Aquariophile: welches debian/ welche xfree version? Aquariophile woody Aquariophile Xfree version 86 pgp5fZQB3Xj20.pgp Description: PGP signature
Re: Dogme05: Team Maintenance
[W. Borgert] as a conclusion of many discussions at DebConf5, I propose to maintain all packages by teams. I agree that it is good to maintain packages in teams, to make sure the project is less vulnerable to single maintainers going on vacation, becoming sick, being run over by a bus or other things that tend to happen to people from time to time. I really wish all the base packages was maintained in teams, as these are vital for the stability and progress of the debian distribution. It might be a nice goal to get all packages maintained by teams, but seeing that some people have problems with team work, I suspect it will be hard to achieve. I welcome co-maintainers for all of my packages, and hope the rest of the debian developers maintaining packages will do the same. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
W. Borgert wrote: VIII. Packages not maintained by teams are not to go into unstable/testing/stable. Does this mean you are volunteering as a team member for all packages that currently have only one maintainer? -- Antti-Juhani signature.asc Description: OpenPGP digital signature
Re: Dogme05: Team Maintenance
On Aug 14, W. Borgert [EMAIL PROTECTED] wrote: as a conclusion of many discussions at DebConf5, I propose to maintain all packages by teams. A fine way to do this, is by One size fits all methods are a bad idea. Different packages and different maintainers have different requirements. -- ciao, Marco signature.asc Description: Digital signature
Re: Dogme05: Team Maintenance
On Sun, Aug 14, 2005 at 08:45:43PM +0200, Marco d'Itri wrote: On Aug 14, W. Borgert [EMAIL PROTECTED] wrote: as a conclusion of many discussions at DebConf5, I propose to maintain all packages by teams. A fine way to do this, is by One size fits all methods are a bad idea. Different packages and different maintainers have different requirements. You would have different teams still, so it's not one size fits all. Cheers, -- W. Borgert [EMAIL PROTECTED], http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sun, 14 Aug 2005, W. Borgert wrote: [snip] IX. As alioth becomes even more important to Debian, we will have to strengthen (HA-ing) this resource. X. Teams shall meet online or in sauna. They are allowed to do DDR or ballroom dancing. [Dogme05 is, of course, a pun on Dogme95.] Haha, this gave me a good laugh for an email. Altho, as far as jokes go, this was rather poorly delivered. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
W. Borgert writes: as a conclusion of many discussions at DebConf5, I propose to maintain all packages by teams. You would have a team maintain 'units'? That's silly. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sun, Aug 14, 2005 at 03:52:55PM -0500, Adam Heath wrote: Haha, this gave me a good laugh for an email. Altho, as far as jokes go, this was rather poorly delivered. If I would make my living as an entertainer or comedian, I would have to live on social security or be hungry :-( Sorry. Cheers, -- W. Borgert [EMAIL PROTECTED], http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sun, Aug 14, 2005 at 03:42:23PM -0500, John Hasler wrote: You would have a team maintain 'units'? That's silly. If the team maintains only the package 'units', yes. If the same team maintains multiple relating packages, it's different. E.g. the Debian XML/SGML group maintains 22 packages. Cheers, -- W. Borgert [EMAIL PROTECTED], http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
[John Hasler] You would have a team maintain 'units'? That's silly. I guess it is equally silly as it is to maintain prebaseconfig in a team. The prebaseconfig package is very simple, and maintained by a team together with a lot of other very simple packages. It works quite well to maintain small and simple packages in a team. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
I wrote: You would have a team maintain 'units'? That's silly. W. Borgert writes: If the team maintains only the package 'units', yes. If the same team maintains multiple relating packages, it's different. There are no packages related to units. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sun, Aug 14, 2005 at 11:28:41PM +0200, Petter Reinholdtsen wrote: I guess it is equally silly as it is to maintain prebaseconfig in a team. The prebaseconfig package is very simple, and maintained by a team together with a lot of other very simple packages. It works quite well to maintain small and simple packages in a team. :) Not all small and simple packages have logical relationships with lots of other packages. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sun, 2005-08-14 at 14:15 +, W. Borgert wrote: as a conclusion of many discussions at DebConf5, I propose to maintain all packages by teams. It's a nice ideal. It is useful to invite non-DDs, esp. upstream developers and people from Debian derivatives to participate in such teams. I've tried that. No luck yet. Assumptions: No arguments against I through IV. V. If not at least two maintainers can be found for a particular package, it is not worthwhile to have it in Debian, at least not in a release. experimental is OK. Says who? I maintain some packages like this. Let's say I support 50 to 100 niche users for a given package, but I'm the only developer in the user community who cares to maintain the package in Debian. I maintain the package well, and my users are happy. I would not be at all happy if my package were forced out of Debian because it's not worthwhile. I think that would be a terrible injustice to my users. VI. The advantages of team maintenance outweigh the problem of team maintenance overhead. In my case, there would be a team of one. I could take a build it and they will come approach, I suppose, but unless by creating the project actually attracted other developers, the team maintenance overhead (basically just startup costs) would outweigh the advantages. Let's just say I'm not overly optimistic about my prospects, given my failure so far to attract another developer to co-maintain with me. Upstream is just too busy doing upstream work, and doesn't want to be bothered with packaging, which I seem to do well enough without their help. VII. Team maintainence helps us to collaborate with upstream and derivers. I collaborate just fine with upstream. However, this collaboration with derviers sounds interesting. I haven't yet spoken with any derivers responsible for my packages. That might be an overlooked source of help for me. Thanks for the reminder that they're out there. VIII. Packages not maintained by teams are not to go into unstable/testing/stable. Again: will a team of one, with a help wanted sign hanging on it suffice? I am ideologically supportive of team maintenance, but pessimistic about the prospects of some useful packages ever having more than one maintainer, because they serve a small subgroup of specialized users within Debian. IX. As alioth becomes even more important to Debian, we will have to strengthen (HA-ing) this resource. HA-ing. I'm sorry. I don't know what you mean. X. Teams shall meet online or in sauna. They are allowed to do DDR or ballroom dancing. Works for me. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sun, Aug 14, 2005 at 02:15:43PM +, W. Borgert wrote: Hi, as a conclusion of many discussions at DebConf5, I propose to maintain all packages by teams. A fine way to do this, is by having a pkg- project at alioth.debian.org. It is useful to invite non-DDs, esp. upstream developers and people from Debian derivatives to participate in such teams. I think the goal is good, but the implementation is not. Why not rather move towards a more BSD approach, where any developer can commit changes to any package? It would work around having the awkwardness of finding members of a team, or alternately, having to convince someone to let you join a particular team. What's more, alioth takes a lot of time to work with. I often do development on machines that are not connected to the 'net at a given time, and upload packages later. I would have no problem hosting my darcs repository on alioth, but I would have a problem having to go to alioth every time I upload a new version, or every time I upload a new package, or whatnot. If it can be integrated in a sane fashion with other parts of Debian, then fine. Otherwise, if it costs me time, I want nothing to do with it. Time I spend mucking around on alioth is time I'm not spending fixing bugs or adding features. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Aug 15, John Goerzen [EMAIL PROTECTED] wrote: Why not rather move towards a more BSD approach, where any developer can commit changes to any package? It would work around having the Any developer can already commit changes to any package. The obvious problem is that it is very hard to have everybody involved agree on non-trivial changes. But I think that encouraging NMUs (even mass-NMUs) for trivial changes would be good. -- ciao, Marco signature.asc Description: Digital signature
Re: Dogme05: Team Maintenance
On Mon, Aug 15, 2005 at 05:08:00AM +0200, Marco d'Itri wrote: On Aug 15, John Goerzen [EMAIL PROTECTED] wrote: Why not rather move towards a more BSD approach, where any developer can commit changes to any package? It would work around having the Any developer can already commit changes to any package. The obvious problem is that it is very hard to have everybody involved agree on non-trivial changes. But I think that encouraging NMUs (even mass-NMUs) for trivial changes would be good. I tend to agree. Personally, I keep all my packages under subversion. While I would certainly welcome help if I started falling behind or otherwise needed it, it would be rather disruptive if someone started uploading updates to my packages without coordination. Regardless of whether or not I agreed with the changes, there is a real problem in the sense that my package under revision control is no longer in sync with whatever is in the archive. I know that NMUs also pose the same problem, but one of the goals behind an NMU should be to upload the *minimal* change that corrects the specific problem. In such cases it should not be too difficult to get back in sync. There would either have to be a) some agreed upon central repository for *all* packages, or b) coordination between the primary team or maintainer. Option b is essentially what we do now, just that the coordination is typically done in the form of patches. I.e., people don't go around randomly uploading other people's packages. Option a is likely doomed to fail since revision control tool choices are like a choice of text editor or religion. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpkKeLDwA2pP.pgp Description: PGP signature
Re: Dogme05: Team Maintenance
On Sun, 14 Aug 2005, Roberto C. Sanchez wrote: Regardless of whether or not I agreed with the changes, there is a real problem in the sense that my package under revision control is no longer in sync with whatever is in the archive. I know that NMUs also pose the same problem, but one of the goals behind an NMU should be to upload the *minimal* change that corrects the specific problem. In such cases it should not be too difficult to get back in sync. Actually, this brings up an interesting point. When a new source gets uploaded, it replaces the previous. If several NMUs occur, each one replaces the former. So, when the real maintainer(s) wake up, they can only see the most recent NMU that took place. It'd be nice if NMUs source uploads were auto-archived. Of course, this would be solved by the idea that people have thrown around: checking every source upload into revision control. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
