Re: tb's questions for the candidates
* Branden Robinson [EMAIL PROTECTED] [2004-03-19 18:19]: action (We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages.) do you I do that and I never said otherwise. Well, actually, you said: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. ...in Message-id: [EMAIL PROTECTED][1] Right, I see were the misunderstanding comes from. Let's quote the whole text from http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00201.html * Branden Robinson [EMAIL PROTECTED] [2004-03-04 21:21]: People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. I should not have quoted both sentences you said. My I disagree with this refers to your first sentence only. I agree with the second sentence. My disagreement was only about re-admission to the project where I think they should not be treated the same, not about thanking them for the work they've done. Sorry for the confusion. -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Fri, Mar 12, 2004 at 05:03:56PM +, Martin Michlmayr wrote: * Branden Robinson [EMAIL PROTECTED] [2004-03-12 11:00]: So, given that you don't think maintainers who neglect their duties and don't follow documented procedures should be treated the same as maintainers who leave the project properly, how do you propose to treat them? [...] ...but you do want to make sure they're not retired with full honors, right? Oh, they are retired with full honours. Once we get around to creating a web site listing and thanking emeritus developers, I won't propose splitting it into good people who left the project properly and bad people who didn't. I honour everyone for their contribution, and I have no idea where you get the idea from that this is not the case. Well, I have to admit -- I got it from your own statements on the subject. Earlier in this thread[1], we had the following exchange: * Branden Robinson [EMAIL PROTECTED] [2004-03-04 21:21]: People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. [back to the present] I have only talked about the re-admission of people to the project. Okay. When I was talking about something *other* than re-admission of people to the project, you were quick to disagree with me. Significantly, the above exchange I quoted constituted your entire message, aside from a footnote to the Developer's Reference. How on earth was I to grasp any other context for your words? [snip] I don't see how this position is so different from the one you described later, when you said On the gripping hand, I believe any procedure permitting an emeritus developer back into the project should evaluate the circumstances surrounding their departure. [...] We can make those questions a little more pointed and rigorous for the idlers, if need be. Obviously you suggest treating them differently, too? Sure -- which is why I don't understand where your I disagree with this came from. action (We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages.) do you I do that and I never said otherwise. Well, actually, you said: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. ...in Message-id: [EMAIL PROTECTED][1] By the way, I didn't imply you'd threaten people with being barred from re-admission. What I said was: [...] And before that paragraph, you said I don't think you're going to persuade more people to avoid silently idling out by threatening some sort of denigrated status. Yes. I don't know else I'm supposed to interpret your reply of I disagree with this. to my statement of People who have simply become inactive should be treated as much like those who have resigned as possible.. (Anyway, I perform this work with my QA hat and not with my DPL hat, so it's not really relevant to the discussion; Eh? It is if you ask the DAMs to retire the developer without any request on his or her part. Have you ever done so? As DPL, no. As QA person, I helped the DAM evaluate his listing of inactive people before he performed the MIA ping. I have a question to you. Do you think the MIA ping the DAM performed was a good or bad idea? (i.e. looking for inactive people, asking them if they are still active and if not retiring their accounts in order to minimize stale accounts and maximize security). I think it's a good idea, and I recall applauding you on the subject at DebConf 3. Last November's security breach of our systems via a developer account underscores the importance of vigilance in this area. [1] http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00201.html -- G. Branden Robinson| Debian GNU/Linux |Yeah, that's what Jesus would do. [EMAIL PROTECTED] |Jesus would bomb Afghanistan. Yeah. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: tb's questions for the candidates
* Branden Robinson [EMAIL PROTECTED] [2004-03-19 18:19]: action (We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages.) do you I do that and I never said otherwise. Well, actually, you said: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. ...in Message-id: [EMAIL PROTECTED][1] Right, I see were the misunderstanding comes from. Let's quote the whole text from http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00201.html * Branden Robinson [EMAIL PROTECTED] [2004-03-04 21:21]: People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. I should not have quoted both sentences you said. My I disagree with this refers to your first sentence only. I agree with the second sentence. My disagreement was only about re-admission to the project where I think they should not be treated the same, not about thanking them for the work they've done. Sorry for the confusion. -- Martin Michlmayr [EMAIL PROTECTED]
Re: tb's questions for the candidates
* Anthony Towns aj@azure.humbug.org.au [2004-03-13 14:46]: retired can simply get added again, and that others have to do more checks. So, is it possible for them to fail these checks? If one of them is: Last time you were in Debian, you dropped out of contact for six months, your packages got NMUed and orphaned, and your account got disabled after you didn't reply to a maintainer ping. Are you going to do better this time? Probably not. Well, I don't think asking a question like this makes sense anyway. It's much better to look at the actual behaviour. While technical or philosophical questions can easily be asking with a rigid set of questions, this does not apply to the question whether someone has enough time and motivation. So I think the check would be in a way where the AM looks at the behaviour and can from this draw conclusions and suggests, such as suggest that the maintainer should get co-maintainers. In general, I don't think that orphaning the packages of an inactive maintainer is the best solution. Unfortunately, it's the only solution we have at the moment, but we certainly have to find better ways. One better solution is to have co-maintainers. Another solution is to have a group of QA people who are willing to help busy maintainers for a few months. At the moment, we unfortunately cannot tell a busy maintainer, it's okay, we'll take care of your packages while you're busy. However, I hope to help building a QA team which will provide this service. This is much more useful then orphaning a package, and then removing it a few months later because nobody picked it up (which happens more than you might think). [ Also, removing packages is not the best solution, as mentioned previously, because the user's are no longer supported. ] -- Martin Michlmayr [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Thu, Mar 11, 2004 at 06:19:46PM +, Martin Michlmayr wrote: * Branden Robinson [EMAIL PROTECTED] [2004-03-09 01:07]: I fully agree with you that it's important to follow the documented procedure when leaving the project, but I don't think you're going to persuade more people to avoid silently idling out by threatening some sort of denigrated status. People at risk of doing so are only going to brought back from the brink by some sort of *postitive* reinforcement, not the threat of punishment. Just for the record, I don't threaten people to denigrate their status. Okay. Let's recall the exchange that led to my paragraph you quoted above: On Fri, Mar 05, 2004 at 02:49:23AM +, Martin Michlmayr wrote: * Branden Robinson [EMAIL PROTECTED] [2004-03-04 21:21]: People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. So, given that you don't think maintainers who neglect their duties and don't follow documented procedures should be treated the same as maintainers who leave the project properly, how do you propose to treat them? It's clear you want to treat them differently. Do you propose treating them *better* than maintainers who leave the project properly? That hardly seems likely, as I suspect we all want to promote, not discourage, adherence to procedures that make it easier to maintain or improve the quality of our distribution. [description of what you do when people don't actually leave the project snipped] I don't threaten people saying that if they don't retire properly from the project they won't be re-admitted or anything like that. ...but you do want to make sure they're not retired with full honors, right? You don't want to treat them the same as maintainers who leave the project properly, so how do you propose to treat them? If your different treatment isn't distinguishable from a motivational standpoint (lazy maintainer: oh no, I'd better retire properly, or I won't get $FOO), then why bother having a different procedure? Contrarily, if the unspecified different treatment you propose *is* distinguishable from a motivational standpoint, how could a reasonable person not view it as punishment? What parts of my suggested course of action (We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages.) do you propose we *not* do for maintainers whom we cannot locate, or who refuse to retire according to the proper procedure? By the way, I didn't imply you'd threaten people with being barred from re-admission. What I said was: I believe any procedure permitting an emeritus developer back into the project should evaluate the circumstances surrounding their departure. Both for people who properly resigned and for those who idled out, we're going to need to be asking them if they think they'll have the time and energy to uphold their responsibilities this time around. We can make those questions a little more pointed and rigorous for the idlers, if need be. Let's also not forget that we can actually refuse them re-entry, if they really have lost that much of our respect. ...so I'd be most grateful if you wouldn't quote me out of context. (Anyway, I perform this work with my QA hat and not with my DPL hat, so it's not really relevant to the discussion; Eh? It is if you ask the DAMs to retire the developer without any request on his or her part. Have you ever done so? -- G. Branden Robinson| It doesn't matter what you are Debian GNU/Linux | doing, emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: tb's questions for the candidates
On Fri, Mar 12, 2004 at 05:03:56PM +, Martin Michlmayr wrote: I have only talked about the re-admission of people to the project. When someone wants to join again, you obviously look at what kind of work they did in the past. [...] I said, in a nutshell, that generally people who've retired can simply get added again, and that others have to do more checks. So, is it possible for them to fail these checks? If one of them is: Last time you were in Debian, you dropped out of contact for six months, your packages got NMUed and orphaned, and your account got disabled after you didn't reply to a maintainer ping. Are you going to do better this time? Probably not. are we going to say Well, then screw you. and not allow them to do uploads? What's that achieving apart from throwing away the contribution they would've made in the months before they flaked out? The alternate way of looking at this -- which TBH, is closer to what I'd've expected from Martin -- is, if we're not going to reject these people, or force them through a n-m process they've already passed, that we should be offering some more focussed advice for new-maintainers that've been known to flake out; eg encouraging them to co-maintain their packages so that their co-maintainers will be able to keep the package maintained if they disappear, or similar. But the corollary to that view is that this isn't a way of protecting ourselves from slack maintainers -- because we're just offering help to them, if they refuse that, that's their own choice. OTOH, that's not to say we don't have any protection: that's what the QA group and NMUs provide. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
On Thu, Mar 11, 2004 at 06:19:46PM +, Martin Michlmayr wrote: * Branden Robinson [EMAIL PROTECTED] [2004-03-09 01:07]: I fully agree with you that it's important to follow the documented procedure when leaving the project, but I don't think you're going to persuade more people to avoid silently idling out by threatening some sort of denigrated status. People at risk of doing so are only going to brought back from the brink by some sort of *postitive* reinforcement, not the threat of punishment. Just for the record, I don't threaten people to denigrate their status. Okay. Let's recall the exchange that led to my paragraph you quoted above: On Fri, Mar 05, 2004 at 02:49:23AM +, Martin Michlmayr wrote: * Branden Robinson [EMAIL PROTECTED] [2004-03-04 21:21]: People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. So, given that you don't think maintainers who neglect their duties and don't follow documented procedures should be treated the same as maintainers who leave the project properly, how do you propose to treat them? It's clear you want to treat them differently. Do you propose treating them *better* than maintainers who leave the project properly? That hardly seems likely, as I suspect we all want to promote, not discourage, adherence to procedures that make it easier to maintain or improve the quality of our distribution. [description of what you do when people don't actually leave the project snipped] I don't threaten people saying that if they don't retire properly from the project they won't be re-admitted or anything like that. ...but you do want to make sure they're not retired with full honors, right? You don't want to treat them the same as maintainers who leave the project properly, so how do you propose to treat them? If your different treatment isn't distinguishable from a motivational standpoint (lazy maintainer: oh no, I'd better retire properly, or I won't get $FOO), then why bother having a different procedure? Contrarily, if the unspecified different treatment you propose *is* distinguishable from a motivational standpoint, how could a reasonable person not view it as punishment? What parts of my suggested course of action (We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages.) do you propose we *not* do for maintainers whom we cannot locate, or who refuse to retire according to the proper procedure? By the way, I didn't imply you'd threaten people with being barred from re-admission. What I said was: I believe any procedure permitting an emeritus developer back into the project should evaluate the circumstances surrounding their departure. Both for people who properly resigned and for those who idled out, we're going to need to be asking them if they think they'll have the time and energy to uphold their responsibilities this time around. We can make those questions a little more pointed and rigorous for the idlers, if need be. Let's also not forget that we can actually refuse them re-entry, if they really have lost that much of our respect. ...so I'd be most grateful if you wouldn't quote me out of context. (Anyway, I perform this work with my QA hat and not with my DPL hat, so it's not really relevant to the discussion; Eh? It is if you ask the DAMs to retire the developer without any request on his or her part. Have you ever done so? -- G. Branden Robinson| It doesn't matter what you are Debian GNU/Linux | doing, emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: tb's questions for the candidates
* Branden Robinson [EMAIL PROTECTED] [2004-03-12 11:00]: So, given that you don't think maintainers who neglect their duties and don't follow documented procedures should be treated the same as maintainers who leave the project properly, how do you propose to treat them? [...] ...but you do want to make sure they're not retired with full honors, right? Oh, they are retired with full honours. Once we get around to creating a web site listing and thanking emeritus developers, I won't propose splitting it into good people who left the project properly and bad people who didn't. I honour everyone for their contribution, and I have no idea where you get the idea from that this is not the case. I have only talked about the re-admission of people to the project. When someone wants to join again, you obviously look at what kind of work they did in the past. If they retired, it is more likely that they can judge their workload, whether they have enough time, etc than if they did not retire. This should be taken into account during re-admission. I said, in a nutshell, that generally people who've retired can simply get added again, and that others have to do more checks. Again, this is in a nutshell; it of course depends on the individual circumstances. I don't see how this position is so different from the one you described later, when you said On the gripping hand, I believe any procedure permitting an emeritus developer back into the project should evaluate the circumstances surrounding their departure. [...] We can make those questions a little more pointed and rigorous for the idlers, if need be. Obviously you suggest treating them differently, too? action (We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages.) do you I do that and I never said otherwise. By the way, I didn't imply you'd threaten people with being barred from re-admission. What I said was: [...] And before that paragraph, you said I don't think you're going to persuade more people to avoid silently idling out by threatening some sort of denigrated status. (Anyway, I perform this work with my QA hat and not with my DPL hat, so it's not really relevant to the discussion; Eh? It is if you ask the DAMs to retire the developer without any request on his or her part. Have you ever done so? As DPL, no. As QA person, I helped the DAM evaluate his listing of inactive people before he performed the MIA ping. I have a question to you. Do you think the MIA ping the DAM performed was a good or bad idea? (i.e. looking for inactive people, asking them if they are still active and if not retiring their accounts in order to minimize stale accounts and maximize security). -- Martin Michlmayr [EMAIL PROTECTED]
Re: tb's questions for the candidates
* Thomas Bushnell, BSG [EMAIL PROTECTED] [2004-03-08 22:16]: wonder if the candidates might turn to the following for a moment: Are there circumstances, other than a violation of the DMUP or inactivity, for which a maintainer should be excluded from the Project? Should we think about having a process now? The DMUP covers some areas, but probably not at all; I can imagine that presenting Debian in a severely bad way in public might lead to the exclusion of a developer as well. There might be other reasons, but I cannot think of any right now. As I said in my last mail, I think we should face *concrete* problems rather than asking very general and hypothetical questions. -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
* Branden Robinson [EMAIL PROTECTED] [2004-03-09 01:07]: I fully agree with you that it's important to follow the documented procedure when leaving the project, but I don't think you're going to persuade more people to avoid silently idling out by threatening some sort of denigrated status. People at risk of doing so are only going to brought back from the brink by some sort of *postitive* reinforcement, not the threat of punishment. Just for the record, I don't threaten people to denigrate their status. When I notice a package which is not being maintained well, I get in contact with the maintainer to see what can be done about the situation. Sometimes, simply getting in contact gives them the motivation to put some energy in their packages. Sometimes they ask for help and then I ask QA members to temporarily help. Sometimes they don't respond and after some more pings I usually orphan the package - I do this in the best interest of Debian as a whole. I don't threaten people saying that if they don't retire properly from the project they won't be re-admitted or anything like that. (Anyway, I perform this work with my QA hat and not with my DPL hat, so it's not really relevant to the discussion; I just wanted to clarify how the work is being performed.) -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
* Thomas Bushnell, BSG [EMAIL PROTECTED] [2004-03-08 22:16]: wonder if the candidates might turn to the following for a moment: Are there circumstances, other than a violation of the DMUP or inactivity, for which a maintainer should be excluded from the Project? Should we think about having a process now? The DMUP covers some areas, but probably not at all; I can imagine that presenting Debian in a severely bad way in public might lead to the exclusion of a developer as well. There might be other reasons, but I cannot think of any right now. As I said in my last mail, I think we should face *concrete* problems rather than asking very general and hypothetical questions. -- Martin Michlmayr [EMAIL PROTECTED]
Re: tb's questions for the candidates
* Branden Robinson [EMAIL PROTECTED] [2004-03-09 01:07]: I fully agree with you that it's important to follow the documented procedure when leaving the project, but I don't think you're going to persuade more people to avoid silently idling out by threatening some sort of denigrated status. People at risk of doing so are only going to brought back from the brink by some sort of *postitive* reinforcement, not the threat of punishment. Just for the record, I don't threaten people to denigrate their status. When I notice a package which is not being maintained well, I get in contact with the maintainer to see what can be done about the situation. Sometimes, simply getting in contact gives them the motivation to put some energy in their packages. Sometimes they ask for help and then I ask QA members to temporarily help. Sometimes they don't respond and after some more pings I usually orphan the package - I do this in the best interest of Debian as a whole. I don't threaten people saying that if they don't retire properly from the project they won't be re-admitted or anything like that. (Anyway, I perform this work with my QA hat and not with my DPL hat, so it's not really relevant to the discussion; I just wanted to clarify how the work is being performed.) -- Martin Michlmayr [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Tue, Mar 09, 2004 at 06:51:38PM -0800, Thomas Bushnell, BSG wrote: Branden Robinson [EMAIL PROTECTED] writes: In other words, do you perceive a concrete need for such process now? If not, do you think we are facing an imminent or serious threat of abuse of power on someone's part in the absense of such a process? Hey, I'm asking the questions here! :) Seriously, my point is suppose someone does something horrible. Not abuse of power per se (we know how to deal with that), but something else. I don't know what. Do you think we should not worry about process until we are faced with John Q. Developer, a big fight on the mailing lists, and the sudden need to think up how to decide if JQD stays or goes? Given the vagueness of your question (something horrible...[n]ot abuse of power...but something else...I don't know what), yes -- I think we should not worry about it until we're faced with it. We don't generally fight for fighting's sake on the mailing lists (at least, not near the *beginning* of a thread), so a list discussion of the infraction is the best first course of action for an almost unbounded problem domain, in my opinion. If you can think of something specific, or at least significantly less vague, I may be able to offer a more detailed answer. -- G. Branden Robinson|Men use thought only to justify Debian GNU/Linux |their wrong doings, and speech only [EMAIL PROTECTED] |to conceal their thoughts. http://people.debian.org/~branden/ |-- Voltaire signature.asc Description: Digital signature
Re: tb's questions for the candidates
On Wed, Mar 10, 2004 at 12:59:48AM -0600, Manoj Srivastava wrote: If the dewveloper has done something horrible, why would there be disagreement as to what to do about them (apart from perhaps a difference in degree)? I think we are far better off treating the situation on its merits, rather than tying our hands with some overweening bureacratic rule book that probably can't even begin to cover the nuances of the situations that can develop. I would rather leave some trust in the individuals who comprise Debian, rather than give in to paronia and try to restrict any options they have with a thicket of rules and regulations and rules lawyers. I don't have a problem with procedures as long as the problem space is understood, because then you can establish criteria for evaluating whether the procedures are effective and worthwhile. Thomas's question seems to me to be pretty close to how will you deal with the unexpected? To which my answer would be, in an ad-hoc manner until we can figure out if the scenario is one we're equipped to handle; if it's not, we choose either to equip ourselves, or cope with it as best we can. -- G. Branden Robinson| The greatest productive force is Debian GNU/Linux | human selfishness. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: tb's questions for the candidates
Hi, Raul Miller wrote: The key issue here is that different people have different takes at different times on actually fullfilling that responsibility. True. But that's not the same as stating theat there is no responsibility there in the first place. I don't have hard-and-fast answers either, but the everybody who vanished can just get their key re-added, no problem is equally wrong (IMHO, anyway), in general, than everybody who comes back needs to go through NM again, no matter why they left. I'm quite happy to leave all the gray area cases in between these extremes to the DAM's (or whoever's) discretion, though. -- Matthias Urlichs
Re: tb's questions for the candidates
On 09 Mar 2004 18:51:38 -0800, Thomas Bushnell, BSG [EMAIL PROTECTED] said: Branden Robinson [EMAIL PROTECTED] writes: In other words, do you perceive a concrete need for such process now? If not, do you think we are facing an imminent or serious threat of abuse of power on someone's part in the absense of such a process? Hey, I'm asking the questions here! :) Seriously, my point is suppose someone does something horrible. Not abuse of power per se (we know how to deal with that), but something else. I don't know what. Do you think we should not worry about process until we are faced with John Q. Developer, a big fight on the mailing lists, and the sudden need to think up how to decide if JQD stays or goes? If the dewveloper has done something horrible, why would there be disagreement as to what to do about them (apart from perhaps a difference in degree)? I think we are far better off treating the situation on its merits, rather than tying our hands with some overweening bureacratic rule book that probably can't even begin to cover the nuances of the situations that can develop. I would rather leave some trust in the individuals who comprise Debian, rather than give in to paronia and try to restrict any options they have with a thicket of rules and regulations and rules lawyers. manoj -- What is wanted is not the will to believe, but the will to find out, which is the exact opposite. Bertrand Russell, _Sceptical_Essays_, 1928 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: tb's questions for the candidates
On Tue, 09 Mar 2004 18:43:21 +0100, Matthias Urlichs [EMAIL PROTECTED] said: Hi, Manoj Srivastava wrote: _If_ I do, however, simply not showing up in an emergency or two (as opposed to resigning properly) will have a _very_ different result WRT both to my standing in the community and my ability to restart when the condition that caused my resignation no longer applies. I see. I volunteer for a bake sale, and my wife breaks her leg and I do not show up, the church excommunicates me? A broken leg is an emergency. A bake sale isn't. I was referring to an emergency call _from the fire service_, not from external circumstances. Great, you can indeed distinguish between them. (I'll leave the question whether I really was _that_ inscrutable, or if Manoj deliberately and/or accidentally misunderstood, up to the readers' consideration.) And I bring to your consideration which one of these analogies is closer to the situation of maintianing a debian package, which any developer can NMU as needed: Is it a life and death situation, like the fireman, or is it closer to signing up for a bake sale, and allowing real life to take precedence? manoj -- Those sages who do harm to no-one, and who are always physically restrained, go to the everlasting abode, reaching which they will face no more suffering. 225 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: tb's questions for the candidates
On Tue, Mar 09, 2004 at 06:51:38PM -0800, Thomas Bushnell, BSG wrote: Branden Robinson [EMAIL PROTECTED] writes: In other words, do you perceive a concrete need for such process now? If not, do you think we are facing an imminent or serious threat of abuse of power on someone's part in the absense of such a process? Hey, I'm asking the questions here! :) Seriously, my point is suppose someone does something horrible. Not abuse of power per se (we know how to deal with that), but something else. I don't know what. Do you think we should not worry about process until we are faced with John Q. Developer, a big fight on the mailing lists, and the sudden need to think up how to decide if JQD stays or goes? Given the vagueness of your question (something horrible...[n]ot abuse of power...but something else...I don't know what), yes -- I think we should not worry about it until we're faced with it. We don't generally fight for fighting's sake on the mailing lists (at least, not near the *beginning* of a thread), so a list discussion of the infraction is the best first course of action for an almost unbounded problem domain, in my opinion. If you can think of something specific, or at least significantly less vague, I may be able to offer a more detailed answer. -- G. Branden Robinson|Men use thought only to justify Debian GNU/Linux |their wrong doings, and speech only [EMAIL PROTECTED] |to conceal their thoughts. http://people.debian.org/~branden/ |-- Voltaire signature.asc Description: Digital signature
Re: tb's questions for the candidates
On Wed, Mar 10, 2004 at 12:59:48AM -0600, Manoj Srivastava wrote: If the dewveloper has done something horrible, why would there be disagreement as to what to do about them (apart from perhaps a difference in degree)? I think we are far better off treating the situation on its merits, rather than tying our hands with some overweening bureacratic rule book that probably can't even begin to cover the nuances of the situations that can develop. I would rather leave some trust in the individuals who comprise Debian, rather than give in to paronia and try to restrict any options they have with a thicket of rules and regulations and rules lawyers. I don't have a problem with procedures as long as the problem space is understood, because then you can establish criteria for evaluating whether the procedures are effective and worthwhile. Thomas's question seems to me to be pretty close to how will you deal with the unexpected? To which my answer would be, in an ad-hoc manner until we can figure out if the scenario is one we're equipped to handle; if it's not, we choose either to equip ourselves, or cope with it as best we can. -- G. Branden Robinson| The greatest productive force is Debian GNU/Linux | human selfishness. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: tb's questions for the candidates
Hi, Manoj Srivastava wrote: _If_ I do, however, simply not showing up in an emergency or two (as opposed to resigning properly) will have a _very_ different result WRT both to my standing in the community and my ability to restart when the condition that caused my resignation no longer applies. I see. I volunteer for a bake sale, and my wife breaks her leg and I do not show up, the church excommunicates me? A broken leg is an emergency. A bake sale isn't. I was referring to an emergency call _from the fire service_, not from external circumstances. (I'll leave the question whether I really was _that_ inscrutable, or if Manoj deliberately and/or accidentally misunderstood, up to the readers' consideration.) -- Matthias Urlichs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Sun, Mar 07, 2004 at 07:08:52PM +0100, Matthias Urlichs wrote: If you actively take on some responsibility and then fail to actually fulfill that responsibility it and/or fail to tell others that somebody else needs to do the job, that _is_ to actively work against these rules and decisions in my book. YMMV, and all that. My position is, though, that this is the way it works in many real-world communities also, and quite frankly I fail to see why it shouldn't work that way in Debian. YMMV indeed. The key issue here is that different people have different takes at different times on actually fullfilling that responsibility. For example, if a person's efforts would be considered adequate at the time, and only in retrospect considered inadequate, what then? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Mon, Mar 08, 2004 at 10:16:58PM -0800, Thomas Bushnell, BSG wrote: The intention of my question was a little different, however, and I wonder if the candidates might turn to the following for a moment: Are there circumstances, other than a violation of the DMUP or inactivity, for which a maintainer should be excluded from the Project? A developer should probably be disciplined if he or she violates General Rule 2.1.1 of the Constitution[1]: Nothing in this constitution imposes an obligation on anyone to do work for the Project. [...] However, they must not actively work against these rules and decisions properly made under them. Should we think about having a process now? I often find it easier to reason from the specific to the general than the other way around. Is there a particular instance of non-DMUP, non-inactivity misconduct you had in mind? In other words, do you perceive a concrete need for such process now? If not, do you think we are facing an imminent or serious threat of abuse of power on someone's part in the absense of such a process? [1] http://www.debian.org/devel/constitution -- G. Branden Robinson| The Bible is probably the most Debian GNU/Linux | genocidal book ever written. [EMAIL PROTECTED] | -- Noam Chomsky http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: tb's questions for the candidates
On Fri, Mar 05, 2004 at 02:49:23AM +, Martin Michlmayr wrote: * Branden Robinson [EMAIL PROTECTED] [2004-03-04 21:21]: People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. I guess I'm just going to have to disagree with you here. I fully agree with you that it's important to follow the documented procedure when leaving the project, but I don't think you're going to persuade more people to avoid silently idling out by threatening some sort of denigrated status. People at risk of doing so are only going to brought back from the brink by some sort of *postitive* reinforcement, not the threat of punishment. On the one hand, I simply don't think that failing to dedicate volunteer time to the project, given that the Constitution recognizes the right of developers to do so[1], is as serious an offense as betraying our trust or taking deliberate action to violate our procedures. Not only would it not be fair to lump inactive volunteers in with such people, but it would undermine the seriousness of explusion from the Project. On the other hand, I don't think it's fruitful to create a lot of categories of dishonor. The general public won't be able to keep them straight (some of our own developers might not, either). On the gripping hand, I believe any procedure permitting an emeritus developer back into the project should evaluate the circumstances surrounding their departure. Both for people who properly resigned and for those who idled out, we're going to need to be asking them if they think they'll have the time and energy to uphold their responsibilities this time around. We can make those questions a little more pointed and rigorous for the idlers, if need be. Let's also not forget that we can actually refuse them re-entry, if they really have lost that much of our respect. [1] http://www.debian.org/devel/constitution -- G. Branden Robinson| It's not a matter of alienating Debian GNU/Linux | authors. They have every right to [EMAIL PROTECTED] | license their software however we http://people.debian.org/~branden/ | like. -- Craig Sanders signature.asc Description: Digital signature
Re: tb's questions for the candidates
So my question about ousting developers has generated a very interesting discussion about the issue of inactive people, and it has been interesting to see the candidates distinguish themselves in their understanding of the issues concerned. The intention of my question was a little different, however, and I wonder if the candidates might turn to the following for a moment: Are there circumstances, other than a violation of the DMUP or inactivity, for which a maintainer should be excluded from the Project? Should we think about having a process now? Thomas
Re: tb's questions for the candidates
Hi, Manoj Srivastava wrote: _If_ I do, however, simply not showing up in an emergency or two (as opposed to resigning properly) will have a _very_ different result WRT both to my standing in the community and my ability to restart when the condition that caused my resignation no longer applies. I see. I volunteer for a bake sale, and my wife breaks her leg and I do not show up, the church excommunicates me? A broken leg is an emergency. A bake sale isn't. I was referring to an emergency call _from the fire service_, not from external circumstances. (I'll leave the question whether I really was _that_ inscrutable, or if Manoj deliberately and/or accidentally misunderstood, up to the readers' consideration.) -- Matthias Urlichs
Re: tb's questions for the candidates
On Sun, Mar 07, 2004 at 07:08:52PM +0100, Matthias Urlichs wrote: If you actively take on some responsibility and then fail to actually fulfill that responsibility it and/or fail to tell others that somebody else needs to do the job, that _is_ to actively work against these rules and decisions in my book. YMMV, and all that. My position is, though, that this is the way it works in many real-world communities also, and quite frankly I fail to see why it shouldn't work that way in Debian. YMMV indeed. The key issue here is that different people have different takes at different times on actually fullfilling that responsibility. For example, if a person's efforts would be considered adequate at the time, and only in retrospect considered inadequate, what then? -- Raul
Re: tb's questions for the candidates
On Mon, Mar 08, 2004 at 10:16:58PM -0800, Thomas Bushnell, BSG wrote: The intention of my question was a little different, however, and I wonder if the candidates might turn to the following for a moment: Are there circumstances, other than a violation of the DMUP or inactivity, for which a maintainer should be excluded from the Project? A developer should probably be disciplined if he or she violates General Rule 2.1.1 of the Constitution[1]: Nothing in this constitution imposes an obligation on anyone to do work for the Project. [...] However, they must not actively work against these rules and decisions properly made under them. Should we think about having a process now? I often find it easier to reason from the specific to the general than the other way around. Is there a particular instance of non-DMUP, non-inactivity misconduct you had in mind? In other words, do you perceive a concrete need for such process now? If not, do you think we are facing an imminent or serious threat of abuse of power on someone's part in the absense of such a process? [1] http://www.debian.org/devel/constitution -- G. Branden Robinson| The Bible is probably the most Debian GNU/Linux | genocidal book ever written. [EMAIL PROTECTED] | -- Noam Chomsky http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: tb's questions for the candidates
Branden Robinson [EMAIL PROTECTED] writes: In other words, do you perceive a concrete need for such process now? If not, do you think we are facing an imminent or serious threat of abuse of power on someone's part in the absense of such a process? Hey, I'm asking the questions here! :) Seriously, my point is suppose someone does something horrible. Not abuse of power per se (we know how to deal with that), but something else. I don't know what. Do you think we should not worry about process until we are faced with John Q. Developer, a big fight on the mailing lists, and the sudden need to think up how to decide if JQD stays or goes? Thomas
Re: tb's questions for the candidates
On Sun, 07 Mar 2004 19:08:52 +0100, Matthias Urlichs [EMAIL PROTECTED] said: Hi, Anthony Towns wrote: On Sun, Mar 07, 2004 at 09:09:40AM +0100, Matthias Urlichs wrote: Hi, Manoj Srivastava wrote: On Fri, 5 Mar 2004 14:32:45 +, Martin Michlmayr [EMAIL PROTECTED] said: They should be treated like people who don't follow their duties, We have duties now? Can you point to me where it says that? I looked all over the constitution, and failed. The Constitution doesn't say that you _have_ to take on the maintenance of packages X, Y and Z, but _if_ you do, you take on the duty of doing so properly, in the manner specified by Policy et al. Eh? No, it doesn't. It says quite the opposite: 1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. So? That's what I said. However, they must not actively work against these rules and decisions properly made under them. If you actively take on some responsibility and then fail to actually fulfill that responsibility it and/or fail to tell others that somebody else needs to do the job, that _is_ to actively work against these rules and decisions in my book. Not in mine. Shall we ask for an official interpretation of the constitution? manoj -- Boob's Law: You always find something in the last place you look. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Sun, 07 Mar 2004 09:09:40 +0100, Matthias Urlichs [EMAIL PROTECTED] said: Hi, Manoj Srivastava wrote: On Fri, 5 Mar 2004 14:32:45 +, Martin Michlmayr [EMAIL PROTECTED] said: They should be treated like people who don't follow their duties, We have duties now? Can you point to me where it says that? I looked all over the constitution, and failed. The Constitution doesn't say that you _have_ to take on the maintenance of packages X, Y and Z, but _if_ you do, you take on the duty of doing so properly, in the manner specified by Policy et al. Really? That is news to me, and I am supposed to know the constitution. Could you please either quote chapter and verse -- or admit that you made it all up to win the argument? Compare with real-world duties. For example, nothing in our community's bylaws states that I _have_ to become a volunteer rescue worker. _If_ I do, however, simply not showing up in an emergency or two (as opposed to resigning properly) will have a _very_ different result WRT both to my standing in the community and my ability to restart when the condition that caused my resignation no longer applies. I see. I volunteer for a bake sale, and my wife breaks her leg and I do not show up, the church excommunicates me? manoj -- Glogg (a traditional Scandinavian holiday drink): fifth of dry red wine fifth of Aquavit 1 and 1/2 inch piece of cinnamon 10 cardamom seeds 1 cup raisins 4 dried figs 1 cup blanched or flaked almonds a few pieces of dried orange peel 5 cloves 1/2 lb. sugar cubes Heat up the wine and hard stuff (which may be substituted with wine for the faint of heart) in a big pot after adding all the other stuff EXCEPT the sugar cubes. Just when it reaches boiling, put the sugar in a wire strainer, moisten it in the hot brew, lift it out and ignite it with a match. Dip the sugar several times in the liquid until it is all dissolved. Serve hot in cups with a few raisins and almonds in each cup. N.B. Aquavit may be hard to find and expensive to boot. Use it only if you really have a deep-seated desire to be fussy, or if you are of Swedish extraction. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Fri, Mar 05, 2004 at 02:49:23AM +, Martin Michlmayr wrote: * Branden Robinson [EMAIL PROTECTED] [2004-03-04 21:21]: People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. I guess I'm just going to have to disagree with you here. I fully agree with you that it's important to follow the documented procedure when leaving the project, but I don't think you're going to persuade more people to avoid silently idling out by threatening some sort of denigrated status. People at risk of doing so are only going to brought back from the brink by some sort of *postitive* reinforcement, not the threat of punishment. On the one hand, I simply don't think that failing to dedicate volunteer time to the project, given that the Constitution recognizes the right of developers to do so[1], is as serious an offense as betraying our trust or taking deliberate action to violate our procedures. Not only would it not be fair to lump inactive volunteers in with such people, but it would undermine the seriousness of explusion from the Project. On the other hand, I don't think it's fruitful to create a lot of categories of dishonor. The general public won't be able to keep them straight (some of our own developers might not, either). On the gripping hand, I believe any procedure permitting an emeritus developer back into the project should evaluate the circumstances surrounding their departure. Both for people who properly resigned and for those who idled out, we're going to need to be asking them if they think they'll have the time and energy to uphold their responsibilities this time around. We can make those questions a little more pointed and rigorous for the idlers, if need be. Let's also not forget that we can actually refuse them re-entry, if they really have lost that much of our respect. [1] http://www.debian.org/devel/constitution -- G. Branden Robinson| It's not a matter of alienating Debian GNU/Linux | authors. They have every right to [EMAIL PROTECTED] | license their software however we http://people.debian.org/~branden/ | like. -- Craig Sanders signature.asc Description: Digital signature
Re: tb's questions for the candidates
So my question about ousting developers has generated a very interesting discussion about the issue of inactive people, and it has been interesting to see the candidates distinguish themselves in their understanding of the issues concerned. The intention of my question was a little different, however, and I wonder if the candidates might turn to the following for a moment: Are there circumstances, other than a violation of the DMUP or inactivity, for which a maintainer should be excluded from the Project? Should we think about having a process now? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Sun, 07 Mar 2004 19:08:52 +0100, Matthias Urlichs [EMAIL PROTECTED] said: Hi, Anthony Towns wrote: On Sun, Mar 07, 2004 at 09:09:40AM +0100, Matthias Urlichs wrote: Hi, Manoj Srivastava wrote: On Fri, 5 Mar 2004 14:32:45 +, Martin Michlmayr [EMAIL PROTECTED] said: They should be treated like people who don't follow their duties, We have duties now? Can you point to me where it says that? I looked all over the constitution, and failed. The Constitution doesn't say that you _have_ to take on the maintenance of packages X, Y and Z, but _if_ you do, you take on the duty of doing so properly, in the manner specified by Policy et al. Eh? No, it doesn't. It says quite the opposite: 1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. So? That's what I said. However, they must not actively work against these rules and decisions properly made under them. If you actively take on some responsibility and then fail to actually fulfill that responsibility it and/or fail to tell others that somebody else needs to do the job, that _is_ to actively work against these rules and decisions in my book. Not in mine. Shall we ask for an official interpretation of the constitution? manoj -- Boob's Law: You always find something in the last place you look. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: tb's questions for the candidates
On Sun, 07 Mar 2004 09:09:40 +0100, Matthias Urlichs [EMAIL PROTECTED] said: Hi, Manoj Srivastava wrote: On Fri, 5 Mar 2004 14:32:45 +, Martin Michlmayr [EMAIL PROTECTED] said: They should be treated like people who don't follow their duties, We have duties now? Can you point to me where it says that? I looked all over the constitution, and failed. The Constitution doesn't say that you _have_ to take on the maintenance of packages X, Y and Z, but _if_ you do, you take on the duty of doing so properly, in the manner specified by Policy et al. Really? That is news to me, and I am supposed to know the constitution. Could you please either quote chapter and verse -- or admit that you made it all up to win the argument? Compare with real-world duties. For example, nothing in our community's bylaws states that I _have_ to become a volunteer rescue worker. _If_ I do, however, simply not showing up in an emergency or two (as opposed to resigning properly) will have a _very_ different result WRT both to my standing in the community and my ability to restart when the condition that caused my resignation no longer applies. I see. I volunteer for a bake sale, and my wife breaks her leg and I do not show up, the church excommunicates me? manoj -- Glogg (a traditional Scandinavian holiday drink): fifth of dry red wine fifth of Aquavit 1 and 1/2 inch piece of cinnamon 10 cardamom seeds 1 cup raisins 4 dried figs 1 cup blanched or flaked almonds a few pieces of dried orange peel 5 cloves 1/2 lb. sugar cubes Heat up the wine and hard stuff (which may be substituted with wine for the faint of heart) in a big pot after adding all the other stuff EXCEPT the sugar cubes. Just when it reaches boiling, put the sugar in a wire strainer, moisten it in the hot brew, lift it out and ignite it with a match. Dip the sugar several times in the liquid until it is all dissolved. Serve hot in cups with a few raisins and almonds in each cup. N.B. Aquavit may be hard to find and expensive to boot. Use it only if you really have a deep-seated desire to be fussy, or if you are of Swedish extraction. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: tb's questions for the candidates
Hi, Anthony Towns wrote: So, for example, I should be put through n-m again immediately because I haven't been doing regular maintenance of cruft or ifupdown? Have you left the project? No? Then why are you asking that question? -- Matthias Urlichs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
Hi, Manoj Srivastava wrote: On Fri, 5 Mar 2004 14:32:45 +, Martin Michlmayr [EMAIL PROTECTED] said: They should be treated like people who don't follow their duties, We have duties now? Can you point to me where it says that? I looked all over the constitution, and failed. The Constitution doesn't say that you _have_ to take on the maintenance of packages X, Y and Z, but _if_ you do, you take on the duty of doing so properly, in the manner specified by Policy et al. Compare with real-world duties. For example, nothing in our community's bylaws states that I _have_ to become a volunteer rescue worker. _If_ I do, however, simply not showing up in an emergency or two (as opposed to resigning properly) will have a _very_ different result WRT both to my standing in the community and my ability to restart when the condition that caused my resignation no longer applies. -- Matthias Urlichs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Sun, Mar 07, 2004 at 09:09:40AM +0100, Matthias Urlichs wrote: Hi, Manoj Srivastava wrote: On Fri, 5 Mar 2004 14:32:45 +, Martin Michlmayr [EMAIL PROTECTED] said: They should be treated like people who don't follow their duties, We have duties now? Can you point to me where it says that? I looked all over the constitution, and failed. The Constitution doesn't say that you _have_ to take on the maintenance of packages X, Y and Z, but _if_ you do, you take on the duty of doing so properly, in the manner specified by Policy et al. Eh? No, it doesn't. It says quite the opposite: 1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them. Anyone surely includes people who are maintainers, considering almost everyone who's covered by the Debian constitution is a maintainer. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
Hi, Anthony Towns wrote: On Sun, Mar 07, 2004 at 09:09:40AM +0100, Matthias Urlichs wrote: Hi, Manoj Srivastava wrote: On Fri, 5 Mar 2004 14:32:45 +, Martin Michlmayr [EMAIL PROTECTED] said: They should be treated like people who don't follow their duties, We have duties now? Can you point to me where it says that? I looked all over the constitution, and failed. The Constitution doesn't say that you _have_ to take on the maintenance of packages X, Y and Z, but _if_ you do, you take on the duty of doing so properly, in the manner specified by Policy et al. Eh? No, it doesn't. It says quite the opposite: 1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. So? That's what I said. However, they must not actively work against these rules and decisions properly made under them. If you actively take on some responsibility and then fail to actually fulfill that responsibility it and/or fail to tell others that somebody else needs to do the job, that _is_ to actively work against these rules and decisions in my book. YMMV, and all that. My position is, though, that this is the way it works in many real-world communities also, and quite frankly I fail to see why it shouldn't work that way in Debian. I'll save the question whether my original mesage was _that_ difficult to understand for some other time if you don't mind. -- Matthias Urlichs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
Matthias Urlichs [EMAIL PROTECTED] writes: If you actively take on some responsibility and then fail to actually fulfill that responsibility it and/or fail to tell others that somebody else needs to do the job, that _is_ to actively work against these rules and decisions in my book. No. That would be to *passively* obstruct the rules, and such passive obstruction is allowed. For this reason the project needs to have things like an NMU procedure and a QA team to carry the slack when someone is inactive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
Hi, Anthony Towns wrote: So, for example, I should be put through n-m again immediately because I haven't been doing regular maintenance of cruft or ifupdown? Have you left the project? No? Then why are you asking that question? -- Matthias Urlichs
Re: tb's questions for the candidates
On Sun, Mar 07, 2004 at 09:09:40AM +0100, Matthias Urlichs wrote: Hi, Manoj Srivastava wrote: On Fri, 5 Mar 2004 14:32:45 +, Martin Michlmayr [EMAIL PROTECTED] said: They should be treated like people who don't follow their duties, We have duties now? Can you point to me where it says that? I looked all over the constitution, and failed. The Constitution doesn't say that you _have_ to take on the maintenance of packages X, Y and Z, but _if_ you do, you take on the duty of doing so properly, in the manner specified by Policy et al. Eh? No, it doesn't. It says quite the opposite: 1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them. Anyone surely includes people who are maintainers, considering almost everyone who's covered by the Debian constitution is a maintainer. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
Hi, Anthony Towns wrote: On Sun, Mar 07, 2004 at 09:09:40AM +0100, Matthias Urlichs wrote: Hi, Manoj Srivastava wrote: On Fri, 5 Mar 2004 14:32:45 +, Martin Michlmayr [EMAIL PROTECTED] said: They should be treated like people who don't follow their duties, We have duties now? Can you point to me where it says that? I looked all over the constitution, and failed. The Constitution doesn't say that you _have_ to take on the maintenance of packages X, Y and Z, but _if_ you do, you take on the duty of doing so properly, in the manner specified by Policy et al. Eh? No, it doesn't. It says quite the opposite: 1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. So? That's what I said. However, they must not actively work against these rules and decisions properly made under them. If you actively take on some responsibility and then fail to actually fulfill that responsibility it and/or fail to tell others that somebody else needs to do the job, that _is_ to actively work against these rules and decisions in my book. YMMV, and all that. My position is, though, that this is the way it works in many real-world communities also, and quite frankly I fail to see why it shouldn't work that way in Debian. I'll save the question whether my original mesage was _that_ difficult to understand for some other time if you don't mind. -- Matthias Urlichs
Re: tb's questions for the candidates
Matthias Urlichs [EMAIL PROTECTED] writes: If you actively take on some responsibility and then fail to actually fulfill that responsibility it and/or fail to tell others that somebody else needs to do the job, that _is_ to actively work against these rules and decisions in my book. No. That would be to *passively* obstruct the rules, and such passive obstruction is allowed. For this reason the project needs to have things like an NMU procedure and a QA team to carry the slack when someone is inactive.
Re: tb's questions for the candidates
* Anthony Towns ([EMAIL PROTECTED]) [040305 16:40]: On Fri, Mar 05, 2004 at 02:32:45PM +, Martin Michlmayr wrote: * Anthony Towns [EMAIL PROTECTED] [2004-03-05 15:25]: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. Then how should they be treated, exactly? They should be treated like people who don't follow their duties, which is what they did. In practice, this means that someone who left Debian properly by resigning can easily come back by mailing the keyring maintainer. Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. So, for example, I should be put through n-m again immediately because I haven't been doing regular maintenance of cruft or ifupdown? I consider this a good idea, yes. Thanks for that proposal. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Sat, Mar 06, 2004 at 10:43:56AM +0100, Andreas Barth wrote: So, for example, I should be put through n-m again immediately because I haven't been doing regular maintenance of cruft or ifupdown? I consider this a good idea, yes. Thanks for that proposal. Why do you think it's a good idea? It certainly makes sense as a punishment. Is that your aim? If not, why do you think it would be anything but a waste of time on my behalf, or my prospective AM's behalf? Wasting time is exactly what you want if it's a punishment, but it's exactly what you don't want if you've got some productive outcome in mind. Or are you just hoping that I won't be willing to do that, and will quit the project instead, just as being forced to go through n-m again will encourage some people not to rejoin the project? In any event, I trust that you'll be following through on your beliefs, and aren't just making snide and offensive remarks on mailing lists for the fun of it. Persuading the DAM to adopt your policy, or proposing a general resolution are your next steps. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
On Fri, Mar 05, 2004 at 11:16:42PM -0600, Steve Langasek wrote: Do you believe instead that their stated willingness to contribute automatically justifies risking the QA/MIA workload associated with cleaning up after the developer if they disappear again? No, I think we need to be able to do QA tasks anyway -- for packages like cruft and ifupdown to use examples that don't need to offend anyone else -- and I don't think there's any benefit to be had from making it hard for people to provide valuable contributions. Why would trying to assure ourselves that developers will follow procedures be a punishment, rather than an act of self-preservation? If it were an act of self-preservation, it'd need to be applied consistently. Badly maintained packages cause the exact same problems whether that's due to someone focussing their efforts elsewhere within Debian, or outside of it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
* Anthony Towns (aj@azure.humbug.org.au) [040305 16:40]: On Fri, Mar 05, 2004 at 02:32:45PM +, Martin Michlmayr wrote: * Anthony Towns aj@azure.humbug.org.au [2004-03-05 15:25]: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. Then how should they be treated, exactly? They should be treated like people who don't follow their duties, which is what they did. In practice, this means that someone who left Debian properly by resigning can easily come back by mailing the keyring maintainer. Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. So, for example, I should be put through n-m again immediately because I haven't been doing regular maintenance of cruft or ifupdown? I consider this a good idea, yes. Thanks for that proposal. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: tb's questions for the candidates
* Anthony Towns [EMAIL PROTECTED] [2004-03-05 15:25]: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. Then how should they be treated, exactly? They should be treated like people who don't follow their duties, which is what they did. In practice, this means that someone who left Debian properly by resigning can easily come back by mailing the keyring maintainer. Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Fri, Mar 05, 2004 at 02:32:45PM +, Martin Michlmayr wrote: * Anthony Towns [EMAIL PROTECTED] [2004-03-05 15:25]: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. Then how should they be treated, exactly? They should be treated like people who don't follow their duties, which is what they did. In practice, this means that someone who left Debian properly by resigning can easily come back by mailing the keyring maintainer. Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. So, for example, I should be put through n-m again immediately because I haven't been doing regular maintenance of cruft or ifupdown? Or if those packages haven't had severe enough bugs for you, perhaps Branden or the entire Progeny staff should be put through n-m again for abandoning pgi which has had an RC bug in unstable for well over a year now? If not, what makes my or their other contributions to the project valuable enough to override that policy, that aren't equally well provided by, say, working on other free software projects, caring for sick family members, serving your country with compulsory military service, making millions by exploiting peasants in third world countries, or veging out in front of the TV? The constitution states as its *first* general rule that Nothing in this constitution imposes an obligation on anyone to do any work for the Project. Debian's policy of treating everyone as a volunteer, and thanking them for what they can do, and not criticising, rebuking, or sanctioning them for what they can't do, or simply chose not to do is valuable and admirable, IMO, and shouldn't be thrown out so casually. As a for instance, IMO one of the problems with expecting people to maintain their packages consistently and well, is that every time there's an NMU then that can only be interpreted as a direct statement that they're not meeting Debian's expectations, and hence that they're a below average maintainer, or worse simply irresponsible. But there're plenty of reasons why people can't maintain their packages at the level we'd like, even if they are competent, and even if they are completely responsible. Life can intervene, your priorities can change, or whatever. There's no reason to imagine maintainer's in that position aren't up to scratch, and the consequence that NMUs have to be looked at as an attack on the maintainer's commitment to the project, rather than a useful contribution from a co-developer and something to be thankful for, is quite a nuisance. I dunno, it just seems that the same people who're wanting Debian to be more encouraging and accessible to newbies, to chicks, or to others, are at the same time being pretty unwelcoming and unencouraging of other contributions, whether that be, eg, James work, which can hardly be mentioned without adding copious criticism, or non-free package maintainers' contributions which all the candidates seem to want dropped from the project, or, evidently, to the contributions of folks who don't offer Debian the same level of dedication our DPL does. (And, obviously, I'm not saying everyone should be let do anything without any oversight at all -- if people don't know what they're doing, we shouldn't be inflicting their shoddy work on our users, and if they're working against our goals, we shouldn't be shy about making sure they can't do us or our users any harm; but if people are slacking off, we're better off making sure we pick that slack up, not make sure there are apropriate punitive procedures in place.) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
On Sat, Mar 06, 2004 at 01:19:01AM +1000, Anthony Towns wrote: On Fri, Mar 05, 2004 at 02:32:45PM +, Martin Michlmayr wrote: * Anthony Towns [EMAIL PROTECTED] [2004-03-05 15:25]: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. Then how should they be treated, exactly? They should be treated like people who don't follow their duties, which is what they did. In practice, this means that someone who left Debian properly by resigning can easily come back by mailing the keyring maintainer. Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. So, for example, I should be put through n-m again immediately because I haven't been doing regular maintenance of cruft or ifupdown? Or if those packages haven't had severe enough bugs for you, perhaps Branden or the entire Progeny staff should be put through n-m again for abandoning pgi which has had an RC bug in unstable for well over a year now? You are way overreacting, probably because a crucial part of Thomas' original post got snipped, which makes it clear that the topic is about closing down accounts, not just about people who don't maintain their packages well and have them orphaned. Orphaning packages has nothing to do with closing down accounts because somebody is MIA, apart from the fact that this is one prerequisite. The former is taken out by QA, the latter by the DAM. James made it pretty clear how he handles this, namely, he sends pings to people who don't have a single package in the archive anymore and are otherwise considered to be MIA (no records of mailing list activity, e.g.) for a considerable amount of time. People who respond to the pings don't have their accounts locked down, AIUI. http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200305/msg6.html Of course, neither you nor Progeny qualify for this (having your account removed), so the rest of your post is moot. FWIW, I agree with Martin on this. If you're *so* MIA that the DAM decides to lock down your account, it's better to get back in touch with policy and stuff. Also note that people who *do* apply again for NM after having resigned sometimes (often?) get their account back immediatly (cf. Lars). cheers, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Fri, 5 Mar 2004 14:32:45 +, Martin Michlmayr [EMAIL PROTECTED] said: * Anthony Towns [EMAIL PROTECTED] [2004-03-05 15:25]: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. Then how should they be treated, exactly? They should be treated like people who don't follow their duties, We have duties now? Can you point to me where it says that? I looked all over the constitution, and failed. which is what they did. In practice, this means that someone who left Debian properly by resigning can easily come back by mailing the keyring maintainer. Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. -- I think we need to ask the NM team where they are making this stuff about duties up from. Since when have we stopped being a collection of volunteers? When did the slave driving start? Can I have a whip? manoj -- May our nation continue to be the beakon of hope to the world. The Quayles' 1989 Christmas card. [Not a beacon of literacy, though.] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Fri, Mar 05, 2004 at 04:54:05PM +0100, Michael Banck wrote: Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. Also note that people who *do* apply again for NM after having resigned sometimes (often?) get their account back immediatly (cf. Lars). AFAIK, they _always_ get their account back immediately without requiring extensive justification (well, presuming they're obviously the same person, and maybe a i'm looking at taking up maintenace of foo.deb explanation is expected -- but those should apply equally to people who retired too). That's not what Martin seems to be saying, though: that seems to be to put them through n-m not as a first point of contact to get their account unlocked, but as a way of retraining them and ensuring they won't be as irresponsible again, and effectively punishing them for not following procedure. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
On Sat, Mar 06, 2004 at 02:37:50PM +1000, Anthony Towns wrote: On Fri, Mar 05, 2004 at 04:54:05PM +0100, Michael Banck wrote: Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. Also note that people who *do* apply again for NM after having resigned sometimes (often?) get their account back immediatly (cf. Lars). AFAIK, they _always_ get their account back immediately without requiring extensive justification (well, presuming they're obviously the same person, and maybe a i'm looking at taking up maintenace of foo.deb explanation is expected -- but those should apply equally to people who retired too). That's not what Martin seems to be saying, though: that seems to be to put them through n-m not as a first point of contact to get their account unlocked, but as a way of retraining them and ensuring they won't be as irresponsible again, and effectively punishing them for not following procedure. Do you believe instead that their stated willingness to contribute automatically justifies risking the QA/MIA workload associated with cleaning up after the developer if they disappear again? Why would trying to assure ourselves that developers will follow procedures be a punishment, rather than an act of self-preservation? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: tb's questions for the candidates
On Fri, Mar 05, 2004 at 11:16:42PM -0600, Steve Langasek wrote: Do you believe instead that their stated willingness to contribute automatically justifies risking the QA/MIA workload associated with cleaning up after the developer if they disappear again? No, I think we need to be able to do QA tasks anyway -- for packages like cruft and ifupdown to use examples that don't need to offend anyone else -- and I don't think there's any benefit to be had from making it hard for people to provide valuable contributions. Why would trying to assure ourselves that developers will follow procedures be a punishment, rather than an act of self-preservation? If it were an act of self-preservation, it'd need to be applied consistently. Badly maintained packages cause the exact same problems whether that's due to someone focussing their efforts elsewhere within Debian, or outside of it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
* Anthony Towns aj@azure.humbug.org.au [2004-03-05 15:25]: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. Then how should they be treated, exactly? They should be treated like people who don't follow their duties, which is what they did. In practice, this means that someone who left Debian properly by resigning can easily come back by mailing the keyring maintainer. Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. -- Martin Michlmayr [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Fri, Mar 05, 2004 at 02:32:45PM +, Martin Michlmayr wrote: * Anthony Towns aj@azure.humbug.org.au [2004-03-05 15:25]: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. Then how should they be treated, exactly? They should be treated like people who don't follow their duties, which is what they did. In practice, this means that someone who left Debian properly by resigning can easily come back by mailing the keyring maintainer. Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. So, for example, I should be put through n-m again immediately because I haven't been doing regular maintenance of cruft or ifupdown? Or if those packages haven't had severe enough bugs for you, perhaps Branden or the entire Progeny staff should be put through n-m again for abandoning pgi which has had an RC bug in unstable for well over a year now? If not, what makes my or their other contributions to the project valuable enough to override that policy, that aren't equally well provided by, say, working on other free software projects, caring for sick family members, serving your country with compulsory military service, making millions by exploiting peasants in third world countries, or veging out in front of the TV? The constitution states as its *first* general rule that Nothing in this constitution imposes an obligation on anyone to do any work for the Project. Debian's policy of treating everyone as a volunteer, and thanking them for what they can do, and not criticising, rebuking, or sanctioning them for what they can't do, or simply chose not to do is valuable and admirable, IMO, and shouldn't be thrown out so casually. As a for instance, IMO one of the problems with expecting people to maintain their packages consistently and well, is that every time there's an NMU then that can only be interpreted as a direct statement that they're not meeting Debian's expectations, and hence that they're a below average maintainer, or worse simply irresponsible. But there're plenty of reasons why people can't maintain their packages at the level we'd like, even if they are competent, and even if they are completely responsible. Life can intervene, your priorities can change, or whatever. There's no reason to imagine maintainer's in that position aren't up to scratch, and the consequence that NMUs have to be looked at as an attack on the maintainer's commitment to the project, rather than a useful contribution from a co-developer and something to be thankful for, is quite a nuisance. I dunno, it just seems that the same people who're wanting Debian to be more encouraging and accessible to newbies, to chicks, or to others, are at the same time being pretty unwelcoming and unencouraging of other contributions, whether that be, eg, James work, which can hardly be mentioned without adding copious criticism, or non-free package maintainers' contributions which all the candidates seem to want dropped from the project, or, evidently, to the contributions of folks who don't offer Debian the same level of dedication our DPL does. (And, obviously, I'm not saying everyone should be let do anything without any oversight at all -- if people don't know what they're doing, we shouldn't be inflicting their shoddy work on our users, and if they're working against our goals, we shouldn't be shy about making sure they can't do us or our users any harm; but if people are slacking off, we're better off making sure we pick that slack up, not make sure there are apropriate punitive procedures in place.) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
On Fri, 5 Mar 2004 14:32:45 +, Martin Michlmayr [EMAIL PROTECTED] said: * Anthony Towns aj@azure.humbug.org.au [2004-03-05 15:25]: I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. Then how should they be treated, exactly? They should be treated like people who don't follow their duties, We have duties now? Can you point to me where it says that? I looked all over the constitution, and failed. which is what they did. In practice, this means that someone who left Debian properly by resigning can easily come back by mailing the keyring maintainer. Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. -- I think we need to ask the NM team where they are making this stuff about duties up from. Since when have we stopped being a collection of volunteers? When did the slave driving start? Can I have a whip? manoj -- May our nation continue to be the beakon of hope to the world. The Quayles' 1989 Christmas card. [Not a beacon of literacy, though.] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: tb's questions for the candidates
On Fri, Mar 05, 2004 at 04:54:05PM +0100, Michael Banck wrote: Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. Also note that people who *do* apply again for NM after having resigned sometimes (often?) get their account back immediatly (cf. Lars). AFAIK, they _always_ get their account back immediately without requiring extensive justification (well, presuming they're obviously the same person, and maybe a i'm looking at taking up maintenace of foo.deb explanation is expected -- but those should apply equally to people who retired too). That's not what Martin seems to be saying, though: that seems to be to put them through n-m not as a first point of contact to get their account unlocked, but as a way of retraining them and ensuring they won't be as irresponsible again, and effectively punishing them for not following procedure. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
On Sat, Mar 06, 2004 at 02:37:50PM +1000, Anthony Towns wrote: On Fri, Mar 05, 2004 at 04:54:05PM +0100, Michael Banck wrote: Those who did not retire properly, on the other hand, will have to go through New Maintainer in order to ensure they understand their duties and procedures in Debian. Also note that people who *do* apply again for NM after having resigned sometimes (often?) get their account back immediatly (cf. Lars). AFAIK, they _always_ get their account back immediately without requiring extensive justification (well, presuming they're obviously the same person, and maybe a i'm looking at taking up maintenace of foo.deb explanation is expected -- but those should apply equally to people who retired too). That's not what Martin seems to be saying, though: that seems to be to put them through n-m not as a first point of contact to get their account unlocked, but as a way of retraining them and ensuring they won't be as irresponsible again, and effectively punishing them for not following procedure. Do you believe instead that their stated willingness to contribute automatically justifies risking the QA/MIA workload associated with cleaning up after the developer if they disappear again? Why would trying to assure ourselves that developers will follow procedures be a punishment, rather than an act of self-preservation? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: tb's questions for the candidates
Gergely Nagy wrote: How would I manage the conflict? There's no problem. I'll just split into two, or duplicate myself. I ... WANT ... THIS ... TECHNOLOGY !!! Regards, Joey -- Linux - the choice of a GNU generation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Thu, Mar 04, 2004 at 08:51:04AM +0100, Martin Schulze wrote: Gergely Nagy wrote: How would I manage the conflict? There's no problem. I'll just split into two, or duplicate myself. I ... WANT ... THIS ... TECHNOLOGY !!! You mean, you want it *back*? Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Wed, Mar 03, 2004 at 07:20:11PM -0800, Thomas Bushnell, BSG wrote: A. What do you think is the greatest challenge facing Debian in the coming year? Ensuring that Debian is well-equipped to grow and enjoy further sucess. What would you do as Project Leader to try and meet this challenge? Reduce opacity of process. Make it easier to find out what the heck's going on, not just with packages (which, as I explained in my platform[1], we already do fairly well), but with people[2][3] and infrastructure as well[4]. B. What should the Project Leader's role be when Debian comes into significant and important conflict with other free software organizations? (As an example, I'm thinking of the conflict with the FSF about the DFSG vs. GNU FDL.) The Project Leader should avoid the temptation to try to be a personal ambassador to every other organization out there. An elected Project Leader should have some confidence that he is perceived as a reasonable and personable individual, but this should not lead the DPL to act if he or she is the only qualified person to conduct business for the project. As noted in my platform[5], something approaching an ambassadorial process would be a good idea. In many cases, we have developers who already have fruitful working relationships with the organizations we're interested in interfacing with. This is a significant advantage of being a large, vigorous, and diverse project, and it is an advantage the DPL should leverage. This is a good way to further increase Debian's status and esteem within the community. C. Being the Project Leader is a major responsibility. What are the other Project-related and non-Project-related responsibilities which would compete for your time, and how would you manage that conflict? I have divested myself of my responsibilities as SPI Treasurer, as noted in an earlier mail to this list[6], and (again as noted in my platform[7]), I have transitioned maintenance of the very large, complex package I maintained (XFree86) to a team-developed model. My primary non-Project responsibility consists of holding down a job. I work for Progeny, a company founded by Ian Murdock (the founder of the Debian Project), use my Debian skills on a daily basis in furtherance of job-related tasks, work alongside other Debian Developers, and am part of an organization that values having a cooperative, respectful relationship with the Debian Project. In significant part, Progeny's business model is founded on the vigor of the Debian Project, and Debian's ability to produce a high-quality operating system. It is difficult for me to imagine a working environment more sympathetic to my responsibilties as DPL, and in the event of any conflict I am quite confident that I will have the ear and cooperation of Progeny management in resolving it. D. People become Debian Maintainers by a complex administrative process, involving three different folks who have to agree on any new Maintainer: the Advocate, the Application Manager, and the Accounts Managers. I'm not interested in the details of how this process works. My question is: Should the Constitution specify at least who has the actual formal approval over this process? In other words, right now it's not clear what the exact lines of authority are. In a word, yes. The New Maintainer Front Desk position was one I identified as one that should be formally delegated in another message to this list[8]. E. Debian does not have a formal process for removing a delinquent developer. Should we have one? And if so, what are the sorts of things for which it would be appropriate to remove a developer? (I'm not inviting speculation here on what such a process would look like.) Yes. I think we should have two avenues of removal; one for people who present disciplinary problems, and one for people who are no longer able to contribute. People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I think of conduct-based dismissals as being of two kinds; one is for activities that expose the Debian Project, a legally-affiliated organization (such as SPI in the U.S.), or another Debian developer to legal liability. I don't think we have much choice but to expel such people on the first offense, and we have done this in the past. The second type of conduct-based dismissal should be for chronic disciplinary problems that do not rise to the level of exposing anyone to criminal or civil liability. This could include obnoxious abuse of the mailing lists or violation of General Rule 2.1.1 in the Constituion[9]: Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not
Re: tb's questions for the candidates
* Branden Robinson [EMAIL PROTECTED] [2004-03-04 21:21]: People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. [1] See section 3.7 Retiring of the Debian Developers' Reference, http://www.debian.org/doc/developers-reference/ch-developer-duties.en.html#s3.7 -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Fri, Mar 05, 2004 at 02:49:23AM +, Martin Michlmayr wrote: * Branden Robinson [EMAIL PROTECTED] [2004-03-04 21:21]: People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. Then how should they be treated, exactly? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
A. What do you think is the greatest challenge facing Debian in the coming year? What would you do as Project Leader to try and meet this challenge? We have quite a few challenges coming ahead. There is this SCO case: we shouldn't laugh too hard at them, because that makes us look bad. Then, we must find the Precious. Last time it was seen on the finger of George Bush, which is quite worrysome to say the least. Mr. Bush being friends with Evil Companies Producing Non-Free Software, it is our duty to retrieve the Ring and destroy it. It is our duty, because we're the distro with the most strict guidelines, and besides, we have the most talented people too ;) Yet another challenge, is making Debian more popular, an idea was suggested by Amaya (in the form of `Debian needs more women'), which I covered in detail here: http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00086.html B. What should the Project Leader's role be when Debian comes into significant and important conflict with other free software organizations? (As an example, I'm thinking of the conflict with the FSF about the DFSG vs. GNU FDL.) I think I partially covered this question in a previous mail, see here: http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00037.html The same approach can be used to solve conflicts with other organisations. I'm working on an ESR skin, and if someone could tell me who do I need to make a voodoo doll about for the XFree license change, I'd be grateful. C. Being the Project Leader is a major responsibility. What are the other Project-related and non-Project-related responsibilities which would compete for your time, and how would you manage that conflict? I'm the primary author of dpatch2, but that codebase has stabilised, so it's not a too tedious task. Other than that, my most important package is tama, and is a great responsibility. As you can see from a few mails of mine (like http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00089.html), breeding a tamagotchi can be quite dangerous, and needs lots of attention. Just like caring for a project would require similar amounts of care and attention. Sometimes, I'd like to think of Debian as a big family of highly themed tamagotchis... At those times, my World Dictator self is ruling my mind, obviously. How would I manage the conflict? There's no problem. I'll just split into two, or duplicate myself. D. People become Debian Maintainers by a complex administrative process, involving three different folks who have to agree on any new Maintainer: the Advocate, the Application Manager, and the Accounts Managers. I'm not interested in the details of how this process works. My question is: Should the Constitution specify at least who has the actual formal approval over this process? In other words, right now it's not clear what the exact lines of authority are. I think our Constitution already specifies who has the final word (DAM), and iirc, and as quoted by Martin, he is a delegate of the DPL. My thinking is, that the line of authority is something like this: Yama (the oversized tamagotchi of mine) spares the life of all who believe in him, so the DPL surviving the apocalypse delegates the DAM. The DAM, so that he doesn't have to do everything by himself, forms the Front Desk, who in turn, delegate the bulk of the job to Application Managers. However, since people suck and nominate^Wapply for fun, the NM Cabal introduced the Advocate step. NM Cabal being the DAM, the Front Desk, the Application Managers and other interested people. Seems pretty clear to me! :) E. Debian does not have a formal process for removing a delinquent developer. Should we have one? And if so, what are the sorts of things for which it would be appropriate to remove a developer? (I'm not inviting speculation here on what such a process would look like.) Yes we should have one. For violating the DMUP, being rude to users and not doing their job as outlined in the developers reference (hi Marillat), calling tama names, frightening away potential female developers, etc, one would need to face serious consequences. Not necessarily a remove from the project... worse. Taking him to a sail in the caribbean on the Sea Monkey, and making him Governor of a deserted island, which has no animals, only a few plants and lots of rum in a hidden cage. However, you didn't want to know the process, so forget the last two sentences, please. The rest, I hope, answers your question. (Though, suggestions to extend my list of BadThingsToDo(tm) are welcome) -- Gergelybrush Nagywood
Re: tb's questions for the candidates
Gergely Nagy wrote: How would I manage the conflict? There's no problem. I'll just split into two, or duplicate myself. I ... WANT ... THIS ... TECHNOLOGY !!! Regards, Joey -- Linux - the choice of a GNU generation.
Re: tb's questions for the candidates
On Thu, Mar 04, 2004 at 08:51:04AM +0100, Martin Schulze wrote: Gergely Nagy wrote: How would I manage the conflict? There's no problem. I'll just split into two, or duplicate myself. I ... WANT ... THIS ... TECHNOLOGY !!! You mean, you want it *back*? Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: tb's questions for the candidates
On Wed, Mar 03, 2004 at 07:20:11PM -0800, Thomas Bushnell, BSG wrote: A. What do you think is the greatest challenge facing Debian in the coming year? Ensuring that Debian is well-equipped to grow and enjoy further sucess. What would you do as Project Leader to try and meet this challenge? Reduce opacity of process. Make it easier to find out what the heck's going on, not just with packages (which, as I explained in my platform[1], we already do fairly well), but with people[2][3] and infrastructure as well[4]. B. What should the Project Leader's role be when Debian comes into significant and important conflict with other free software organizations? (As an example, I'm thinking of the conflict with the FSF about the DFSG vs. GNU FDL.) The Project Leader should avoid the temptation to try to be a personal ambassador to every other organization out there. An elected Project Leader should have some confidence that he is perceived as a reasonable and personable individual, but this should not lead the DPL to act if he or she is the only qualified person to conduct business for the project. As noted in my platform[5], something approaching an ambassadorial process would be a good idea. In many cases, we have developers who already have fruitful working relationships with the organizations we're interested in interfacing with. This is a significant advantage of being a large, vigorous, and diverse project, and it is an advantage the DPL should leverage. This is a good way to further increase Debian's status and esteem within the community. C. Being the Project Leader is a major responsibility. What are the other Project-related and non-Project-related responsibilities which would compete for your time, and how would you manage that conflict? I have divested myself of my responsibilities as SPI Treasurer, as noted in an earlier mail to this list[6], and (again as noted in my platform[7]), I have transitioned maintenance of the very large, complex package I maintained (XFree86) to a team-developed model. My primary non-Project responsibility consists of holding down a job. I work for Progeny, a company founded by Ian Murdock (the founder of the Debian Project), use my Debian skills on a daily basis in furtherance of job-related tasks, work alongside other Debian Developers, and am part of an organization that values having a cooperative, respectful relationship with the Debian Project. In significant part, Progeny's business model is founded on the vigor of the Debian Project, and Debian's ability to produce a high-quality operating system. It is difficult for me to imagine a working environment more sympathetic to my responsibilties as DPL, and in the event of any conflict I am quite confident that I will have the ear and cooperation of Progeny management in resolving it. D. People become Debian Maintainers by a complex administrative process, involving three different folks who have to agree on any new Maintainer: the Advocate, the Application Manager, and the Accounts Managers. I'm not interested in the details of how this process works. My question is: Should the Constitution specify at least who has the actual formal approval over this process? In other words, right now it's not clear what the exact lines of authority are. In a word, yes. The New Maintainer Front Desk position was one I identified as one that should be formally delegated in another message to this list[8]. E. Debian does not have a formal process for removing a delinquent developer. Should we have one? And if so, what are the sorts of things for which it would be appropriate to remove a developer? (I'm not inviting speculation here on what such a process would look like.) Yes. I think we should have two avenues of removal; one for people who present disciplinary problems, and one for people who are no longer able to contribute. People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I think of conduct-based dismissals as being of two kinds; one is for activities that expose the Debian Project, a legally-affiliated organization (such as SPI in the U.S.), or another Debian developer to legal liability. I don't think we have much choice but to expel such people on the first offense, and we have done this in the past. The second type of conduct-based dismissal should be for chronic disciplinary problems that do not rise to the level of exposing anyone to criminal or civil liability. This could include obnoxious abuse of the mailing lists or violation of General Rule 2.1.1 in the Constituion[9]: Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not
Re: tb's questions for the candidates
* Branden Robinson [EMAIL PROTECTED] [2004-03-04 21:21]: People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. [1] See section 3.7 Retiring of the Debian Developers' Reference, http://www.debian.org/doc/developers-reference/ch-developer-duties.en.html#s3.7 -- Martin Michlmayr [EMAIL PROTECTED]
Re: tb's questions for the candidates
On Fri, Mar 05, 2004 at 02:49:23AM +, Martin Michlmayr wrote: * Branden Robinson [EMAIL PROTECTED] [2004-03-04 21:21]: People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I disagree with this. I think that maintainers who neglect their duties and don't follow documented procedures (orphan their packages, inform the keyring maintainer that they are leaving the project [1]) should not be treated the same as maintainers who leave the project properly. Then how should they be treated, exactly? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: tb's questions for the candidates
* Thomas Bushnell, BSG [EMAIL PROTECTED] [2004-03-03 19:20]: A. What do you think is the greatest challenge facing Debian in the coming year? What would you do as Project Leader to try and meet this challenge? I think I have covered this pretty thoroughly in the My goals section of my platform (http://www.debian.org/vote/2004/platforms/tbm). I think that the first two points in this section are the greatest challenge in the near future: fixing our release cycle, and improving communication in the project, adding more transparency and adding more man power to our core teams. Problems with our release cycle and with communication led to increased frustration in recent months; people are getting demotivated, they have the impression that Debian is falling apart. I think these are the most important problems to tackle in the coming year which is why I say in my platform that we have to put extra emphasis on the internal functions in the coming term. Feel free to ask more specific questions based on my platform. B. What should the Project Leader's role be when Debian comes into significant and important conflict with other free software organizations? I think it is very important to work together, and to resolve these problems and conflicts. We are _one_ community, and we have to make sure that this remains to be the case. I am also worried about the Free Software and the Open Source communities drifting apart further - there is an increasing number of licenses which are Open Source compliant, but which fail to meet our DFSG. I think we have to work together with other organizations, and not just on a technical basis (where we're doing pretty well). C. Being the Project Leader is a major responsibility. What are the other Project-related and non-Project-related responsibilities which would compete for your time, and how would you manage that conflict? Project-related: I lead the New Maintainer Front Desk, and I am involved in various QA activities, mainly in tracking inactive maintainers. I have shown during my first year as DPL that I can handle these tasks while being DPL. Also, more QA people are getting involved so that should reduce some work load. Non-Project-related: I started a PhD about quality management in free software in January. Fortunately, my PhD and my activities in Debian overlap to some extend. I have shown during the last year that I can work on Debian basically full-time and yet perform my studies with excellent results. I therefore see no conflicts or problems with regards to time. D. People become Debian Maintainers by a complex administrative process, involving three different folks who have to agree on any new Maintainer: the Advocate, the Application Manager, and the Accounts Managers. I'm not interested in the details of how this process works. My question is: Should the Constitution specify at least who has the actual formal approval over this process? In other words, right now it's not clear what the exact lines of authority are. I think it's quite clear who the authority has. The constitution (8.1.2) explicitly grants the rights of including approving or expelling Developers to a delegate, and this delegate is the Debian Account Manager (DAM). As such, the DAM has the overall responsibility for the NM process, with assistance from the NM Front Desk. The NM documentation currently available is quite complete, but rather disorganized and not entirely up-to-date. A complete re-write is on my TODO list (as NM Front Desk), and this re-write will better document procedures for advocates, Application Managers and the DAM. A few months ago, the DAM defined the process for DAM rejections quite clearly. In summary, some procedures are quite well documented, while others (mostly AM related tasks) are to some extend learned by doing (under the supervision of the NM Front Desk). However, more documentation is forthcoming, and a first step were my postings about preparing good AM reports, see http://lists.debian.org/debian-newmaint/2003/debian-newmaint-200303/msg00018.html and http://lists.debian.org/debian-newmaint/2004/debian-newmaint-200402/msg00010.html To summarize: I think the constitution does not need clarification in this regard, but more documentation about the whole NM process is important. E. Debian does not have a formal process for removing a delinquent developer. Should we have one? And if so, what are the sorts of things for which it would be appropriate to remove a developer? Basically, (severe) violations of the DMUP are things which would lead to the removal of a developer. I think a formal process would be good, and I suggest it should be developed when there is a concrete case where the expulsion of a developer is proposed (It would be nice to formalize it now, but given that expulsions are extremely rare I don't think the effort should be spent before there is actually a concrete need for it. If someone is volunteering
Re: tb's questions for the candidates
A. What do you think is the greatest challenge facing Debian in the coming year? What would you do as Project Leader to try and meet this challenge? We have quite a few challenges coming ahead. There is this SCO case: we shouldn't laugh too hard at them, because that makes us look bad. Then, we must find the Precious. Last time it was seen on the finger of George Bush, which is quite worrysome to say the least. Mr. Bush being friends with Evil Companies Producing Non-Free Software, it is our duty to retrieve the Ring and destroy it. It is our duty, because we're the distro with the most strict guidelines, and besides, we have the most talented people too ;) Yet another challenge, is making Debian more popular, an idea was suggested by Amaya (in the form of `Debian needs more women'), which I covered in detail here: http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00086.html B. What should the Project Leader's role be when Debian comes into significant and important conflict with other free software organizations? (As an example, I'm thinking of the conflict with the FSF about the DFSG vs. GNU FDL.) I think I partially covered this question in a previous mail, see here: http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00037.html The same approach can be used to solve conflicts with other organisations. I'm working on an ESR skin, and if someone could tell me who do I need to make a voodoo doll about for the XFree license change, I'd be grateful. C. Being the Project Leader is a major responsibility. What are the other Project-related and non-Project-related responsibilities which would compete for your time, and how would you manage that conflict? I'm the primary author of dpatch2, but that codebase has stabilised, so it's not a too tedious task. Other than that, my most important package is tama, and is a great responsibility. As you can see from a few mails of mine (like http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00089.html), breeding a tamagotchi can be quite dangerous, and needs lots of attention. Just like caring for a project would require similar amounts of care and attention. Sometimes, I'd like to think of Debian as a big family of highly themed tamagotchis... At those times, my World Dictator self is ruling my mind, obviously. How would I manage the conflict? There's no problem. I'll just split into two, or duplicate myself. D. People become Debian Maintainers by a complex administrative process, involving three different folks who have to agree on any new Maintainer: the Advocate, the Application Manager, and the Accounts Managers. I'm not interested in the details of how this process works. My question is: Should the Constitution specify at least who has the actual formal approval over this process? In other words, right now it's not clear what the exact lines of authority are. I think our Constitution already specifies who has the final word (DAM), and iirc, and as quoted by Martin, he is a delegate of the DPL. My thinking is, that the line of authority is something like this: Yama (the oversized tamagotchi of mine) spares the life of all who believe in him, so the DPL surviving the apocalypse delegates the DAM. The DAM, so that he doesn't have to do everything by himself, forms the Front Desk, who in turn, delegate the bulk of the job to Application Managers. However, since people suck and nominate^Wapply for fun, the NM Cabal introduced the Advocate step. NM Cabal being the DAM, the Front Desk, the Application Managers and other interested people. Seems pretty clear to me! :) E. Debian does not have a formal process for removing a delinquent developer. Should we have one? And if so, what are the sorts of things for which it would be appropriate to remove a developer? (I'm not inviting speculation here on what such a process would look like.) Yes we should have one. For violating the DMUP, being rude to users and not doing their job as outlined in the developers reference (hi Marillat), calling tama names, frightening away potential female developers, etc, one would need to face serious consequences. Not necessarily a remove from the project... worse. Taking him to a sail in the caribbean on the Sea Monkey, and making him Governor of a deserted island, which has no animals, only a few plants and lots of rum in a hidden cage. However, you didn't want to know the process, so forget the last two sentences, please. The rest, I hope, answers your question. (Though, suggestions to extend my list of BadThingsToDo(tm) are welcome) -- Gergelybrush Nagywood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tb's questions for the candidates
* Thomas Bushnell, BSG [EMAIL PROTECTED] [2004-03-03 19:20]: A. What do you think is the greatest challenge facing Debian in the coming year? What would you do as Project Leader to try and meet this challenge? I think I have covered this pretty thoroughly in the My goals section of my platform (http://www.debian.org/vote/2004/platforms/tbm). I think that the first two points in this section are the greatest challenge in the near future: fixing our release cycle, and improving communication in the project, adding more transparency and adding more man power to our core teams. Problems with our release cycle and with communication led to increased frustration in recent months; people are getting demotivated, they have the impression that Debian is falling apart. I think these are the most important problems to tackle in the coming year which is why I say in my platform that we have to put extra emphasis on the internal functions in the coming term. Feel free to ask more specific questions based on my platform. B. What should the Project Leader's role be when Debian comes into significant and important conflict with other free software organizations? I think it is very important to work together, and to resolve these problems and conflicts. We are _one_ community, and we have to make sure that this remains to be the case. I am also worried about the Free Software and the Open Source communities drifting apart further - there is an increasing number of licenses which are Open Source compliant, but which fail to meet our DFSG. I think we have to work together with other organizations, and not just on a technical basis (where we're doing pretty well). C. Being the Project Leader is a major responsibility. What are the other Project-related and non-Project-related responsibilities which would compete for your time, and how would you manage that conflict? Project-related: I lead the New Maintainer Front Desk, and I am involved in various QA activities, mainly in tracking inactive maintainers. I have shown during my first year as DPL that I can handle these tasks while being DPL. Also, more QA people are getting involved so that should reduce some work load. Non-Project-related: I started a PhD about quality management in free software in January. Fortunately, my PhD and my activities in Debian overlap to some extend. I have shown during the last year that I can work on Debian basically full-time and yet perform my studies with excellent results. I therefore see no conflicts or problems with regards to time. D. People become Debian Maintainers by a complex administrative process, involving three different folks who have to agree on any new Maintainer: the Advocate, the Application Manager, and the Accounts Managers. I'm not interested in the details of how this process works. My question is: Should the Constitution specify at least who has the actual formal approval over this process? In other words, right now it's not clear what the exact lines of authority are. I think it's quite clear who the authority has. The constitution (8.1.2) explicitly grants the rights of including approving or expelling Developers to a delegate, and this delegate is the Debian Account Manager (DAM). As such, the DAM has the overall responsibility for the NM process, with assistance from the NM Front Desk. The NM documentation currently available is quite complete, but rather disorganized and not entirely up-to-date. A complete re-write is on my TODO list (as NM Front Desk), and this re-write will better document procedures for advocates, Application Managers and the DAM. A few months ago, the DAM defined the process for DAM rejections quite clearly. In summary, some procedures are quite well documented, while others (mostly AM related tasks) are to some extend learned by doing (under the supervision of the NM Front Desk). However, more documentation is forthcoming, and a first step were my postings about preparing good AM reports, see http://lists.debian.org/debian-newmaint/2003/debian-newmaint-200303/msg00018.html and http://lists.debian.org/debian-newmaint/2004/debian-newmaint-200402/msg00010.html To summarize: I think the constitution does not need clarification in this regard, but more documentation about the whole NM process is important. E. Debian does not have a formal process for removing a delinquent developer. Should we have one? And if so, what are the sorts of things for which it would be appropriate to remove a developer? Basically, (severe) violations of the DMUP are things which would lead to the removal of a developer. I think a formal process would be good, and I suggest it should be developed when there is a concrete case where the expulsion of a developer is proposed (It would be nice to formalize it now, but given that expulsions are extremely rare I don't think the effort should be spent before there is actually a concrete need for it. If someone is volunteering
