Re: Question for candidate Towns
martin f krafft wrote: also sprach Martin Schulze [EMAIL PROTECTED] [2005.03.11.1715 +0100]: That people who would like to know more about Debian internals have no easy way of finding out, and if they approach those that know at the wrong time, or not in the way those would expect, they get flamed and blacklisted. As you weren't able to provide a single problem (but only listed a non-problem), I consider you're just a firefeeder. This is part of the problem: you (as well as some others) are in a situation in which you fail to understand how others in the project feel. You know a lot about the project, so it's all obvious to you. There are people among us who have not been part of Debian since 1.1, but who would like to know more about what's happening behind the curtains. However, those people are often told to RTFM or go spend time in the code, or just not taken seriously. When the code is public, rtfm is the proper answer. One might add document it properly afterwards as well, though. When the data is available as well, that's best. Some data cannot be made available for legal or other binding obligations (new queue, security archive). If you feel that some bits are missing and need to be documented better, point them out and get them documented better, maybe by doing it on your own. I know a lot about the project because I've been involved in many parts. Other developers are involved in many parts as well. Some other developers mostly whine about not being involved without trying to understand. *sigh* No, I do not have (nor do I want to present) a single example for you, Joey. I am sure that you will dissect just about anything I write. All the better if there is an easy way to find out I hope to be able to, but I cannot guarantee that I am. I believe that most parts of the project are either documented or publically available in source form so that all developers can educate themselves. everything about the project. It just does not help much if every aspect is documented in a different place, or using a different paradigm. Then try to unite the documentation instead of blindly bashing and whining. What you fail to see is that there is something daunting about a project of this size and complexity to those who are trying to understand it top-down, rather than having been part of building it bottom-up. What you fail to see is that the bits are available and that you only have to build the large picture. If you're too lazy to do so, it's not the job of the people working on essential corners of the project to educate every random Johnny Sixpack for the sake of it. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: Yes, but this doesn't *quite* answer my question. The question is whether the bts people will make their own decision about anything, or just do whatever the maintainer says. Of course they'll look over whatever bug you claim is being abused. I don't understand why you'd even imagine it'd be otherwise. I think what I would prefer for cases like this is to remain somewhat arms-length. Human nature is naturally likely to let one's judgment be clouded be emotional investment in a particular case (as it clearly was for the other side too). Really? I think Enrico's take was that wishlist items should remain open until they were no longer a wishlist item. That's a perfectly consistent and reasonable viewpoint, and it's not one that I think he got confused over. Also, the above's getting pretty off-topic -- it's no longer about the DPL stuff, and it's not even about anything happening currently, and it's even getting kinda close to just being a random personal attack about events from a year ago -- focussing as it does on whether I, personally, get different standards to everyone else in the project and am thus by implication some sort of immoral tyrant -- rather than anything particularly technical (since after all you've explicitly agreed the right outcome was reached). No no, not some kind of immoral tyrant, geez no. I'm asking something else, I think. I want a DPL who doesn't use the particular prerogatives of *that* office to get a special pass on issues relating to his own packages or his own commitments in other areas of the project. There aren't many prerogatives for the DPL though. You get to: * lead discussion (9) * propose GRs (5), vary discussion periods (8) and use a casting vote (7) * lend authority to people (2) * appoint people to the tech ctte (6) * appoint delegates (1) * direct SPI to spend money (10) * make decisions requiring urgent action (3) or that no one else can make (4) The first three don't have any direct effect, the second three are at arm's length anyway, and the last one is fairly rare at best, and afaics trying to make it at arm's length would defeat the entire purpose of those provisions. I'm not attacking at all; I'm not accusing you of any kind of impropriety. But what is crucial is the avoidance of the *appearance* of any impropriety. Mmm. I'm not really sure that You're not acting improperly, it just *looks* like your acting improperly is really that much better than attack. And I'd much rather focus on making good decisions rather than worrying too much about appearances -- or to put it another way, I think we've got enough problems that definitely exist and have already manifested themselves than to spend much time worrying about ones that're as yet only imagined. Now as I grant above, in this case there is hardly any irrevocable action undertaken, so the reasons for hesitancy are different. Does that explain both my worries, why I'm not *upset* at you about a decision that was, as regards its merit, clearly right in my opinion, and why I think this is about the DPL election and future directed events, and not a rehash of the past? Yes -- in an ideal world, you'd've pointed this out originally, rather than risking the thread veering off track. :) In other words, what I wish you had done would have been to ask another person with BTS-oversight bits to say: can you look at this case and see if it warrants removing so-and-so from bts-control-bot privs for a space? Mmm. In an ideal world. In practice, that would've forced someone else on the BTS team to have to defend their actions against a fairly hostile and unrestrained -devel, which isn't something I'm willing to ask of people I consider friends. If you look through that thread you can see Colin doing his best to avoid being too involved, for example. He's very sensible. It's not a *fault* that you didn't do this, but it would have demonstrated a strong awareness of the issues here. Would you agree that a procedure like this can be important and think about it in the future? I would really like the circumstances to be different so that I could agree with that, and that's why I'm all for toning down the lists. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Anthony Towns aj@azure.humbug.org.au writes: I'm not attacking at all; I'm not accusing you of any kind of impropriety. But what is crucial is the avoidance of the *appearance* of any impropriety. Mmm. I'm not really sure that You're not acting improperly, it just *looks* like your acting improperly is really that much better than attack. Do you understand why judges aren't allowed to judge their own cases? Hint: it is not because we don't trust judges. Now as I grant above, in this case there is hardly any irrevocable action undertaken, so the reasons for hesitancy are different. Does that explain both my worries, why I'm not *upset* at you about a decision that was, as regards its merit, clearly right in my opinion, and why I think this is about the DPL election and future directed events, and not a rehash of the past? Yes -- in an ideal world, you'd've pointed this out originally, rather than risking the thread veering off track. :) I thought it was obvious; when it became clear that I was wrong about that, I made it explicit. Mmm. In an ideal world. In practice, that would've forced someone else on the BTS team to have to defend their actions against a fairly hostile and unrestrained -devel, which isn't something I'm willing to ask of people I consider friends. Shouldn't we expect people who make such decisions to defend their actions? That doesn't require them to answer long tedious flame wars, but it should involve something like a clearly worded explanation saying this was what was done, this was why, such that people can look at it and say, yes, that is what the real thought process behind the decision was. That's what judges are expected to do, for example. Even if one disagrees with the decision, it is extremely helpful in making it possible for people to predict future decisions. Is it not a good thing to expect people to take responsibility for their actions? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: I'm not attacking at all; I'm not accusing you of any kind of impropriety. But what is crucial is the avoidance of the *appearance* of any impropriety. Mmm. I'm not really sure that You're not acting improperly, it just *looks* like your acting improperly is really that much better than attack. Do you understand why judges aren't allowed to judge their own cases? Hint: it is not because we don't trust judges. See, that was unnecessarily snarky. And yes, it _is_ because we don't trust judges -- and justifiably so, they are deciding life and death cases in politically fraught environments, and there's plenty of history of corruption of judges. The only one of those tags that's remotely applicable to Debian is the politically fraught environment, and IMO, even that shouldn't be so. Mmm. In an ideal world. In practice, that would've forced someone else on the BTS team to have to defend their actions against a fairly hostile and unrestrained -devel, which isn't something I'm willing to ask of people I consider friends. Shouldn't we expect people who make such decisions to defend their actions? That doesn't require them to answer long tedious flame wars, Uh, that's where you're wrong. It does require dealing with long tedious flamewars. I think it shouldn't, and I hope to be able to address that, but for the past few years it certainly has. Is it not a good thing to expect people to take responsibility for their actions? And we're back to snarky. Seriously, how attractive do you think it is to try to communicate on a mailing list when you keep having to put up with innuendo about how you have some policy where certain people such as yourself shouldn't have to take responsibility for their actions? Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Anthony Towns aj@azure.humbug.org.au writes: Do you understand why judges aren't allowed to judge their own cases? Hint: it is not because we don't trust judges. See, that was unnecessarily snarky. And yes, it _is_ because we don't trust judges -- and justifiably so, they are deciding life and death cases in politically fraught environments, and there's plenty of history of corruption of judges. But see, I wasn't trying to be snarky at all. More to the point, I think we need a DPL who is willing to talk to snarky people. Be liberal in what you accept, and conservative in what you require. I've been trying my damnedest to bend over backwards to *not* be snarky in this entire thread, and my experience has been that if there is any conceivable way you could interpret my words as snarky, you seem to me to leap at that opportunity. I would prefer you give me the benefit of the doubt: figure out if there is a *non-snarky* interpretation *first*; and if you can't figure one out, then even then don't assume it's snarky, but ask for clarification. We do not allow judges to judge their own cases *not* because of the great importance of the cases (for we have the same rule for all cases, whether trivial or of great importance), and not because we don't trust the judge. We have it because it is not only important for justice to be done; justice must also be seen to be done. Your style, it seems to me--and *please* correct me where I misunderstand, don't just assume I'm wilfully trying to malign you--seems to be to demand that we must take it on faith that you are doing the right thing, and that you are not willing to open up your decisions to any kind of external examination. Even if you always make the right decisions unfailingly, I also want it to be transparent *that* they are the right decisions. Is it not a good thing to expect people to take responsibility for their actions? And we're back to snarky. Seriously, how attractive do you think it is to try to communicate on a mailing list when you keep having to put up with innuendo about how you have some policy where certain people such as yourself shouldn't have to take responsibility for their actions? Instead of guessing at an emotional subtext for my words, an innuendo or whatever, can you please clarify where I'm wrong? You *seemed* to be suggesting to me that you thought it was not necessary to expect people in leadership roles to justify their actions; that we should simply rely on them being done well, and if we are uncertain or don't understand, we should shut up. If I've gotten it wrong, then please--I beg you--correct me. If you are happy to provide justification for your actions upon request, then please tell me what a proper request looks like. Don't just say it must be non-snarky, tell me what words I should use, and when. Help me out. I want to learn, but you'll have to teach me. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: Do you understand why judges aren't allowed to judge their own cases? Hint: it is not because we don't trust judges. See, that was unnecessarily snarky. But see, I wasn't trying to be snarky at all. No, you weren't, and that's precisely the problem: the habit on the Debian lists is to be unthinkingly obnoxious. That's a problem. More to the point, I think we need a DPL who is willing to talk to snarky people. Oddly enough, I'm still replying. I'm sure you can find plenty of other examples of me talking to snarky people if you troll through the list archives. Be liberal in what you accept, and conservative in what you require. There's a simpler way of saying that in regards to snarkiness: be both tolerant and polite. Do you understand this trivially obvious thing? Obviously you don't, so here's a hint. is not being particularly polite -- it's showing off how smart you are and how dumb your correspondent is. And don't get me wrong -- I'm not saying that's any sort of character flaw on your behalf, and I'm sure I've done the exact same thing repeatedly: half the time it seems *necessary* to be obnoxious on Debian lists to get anywhere. That's a problem too. I've been trying my damnedest to bend over backwards to *not* be snarky in this entire thread, and my experience has been that if there is any conceivable way you could interpret my words as snarky, you seem to me to leap at that opportunity. I would prefer you give me the benefit of the doubt: figure out if there is a *non-snarky* interpretation *first*; and if you can't figure one out, then even then don't assume it's snarky, but ask for clarification. If you don't want to be snarky, here's how you do it: assume the person you're corresponding with is intelligent and shares most of your goals, and just say what you want to say. Don't question their intelligence and drop hints. And yes, it _is_ because we don't trust judges -- and justifiably so, they are deciding life and death cases in politically fraught environments, and there's plenty of history of corruption of judges. We do not allow judges to judge their own cases *not* because of the great importance of the cases (for we have the same rule for all cases, whether trivial or of great importance), and not because we don't trust the judge. We have it because it is not only important for justice to be done; justice must also be seen to be done. For example, by just immediately explaining what you think the point of contention is, rather than trying to be cute about it. It's really not difficult. Anyway; having judges not work on their own topics often _is_ about ensuring they're not biassed or bribed; just as is having lawyers not represent people suing other clients of theirs. Some are completely unimpeachable individuals, certainly, and in many cases judges will offer to recuse themselves and the parties involved will indicate it's unnecessary because of that. But in any case, the primary point of judges recusing themselves is that justice *be* done. Certainly the appearance point is relevant too; but we don't simply trust judges, we have checks and balances and oversight to make sure that if they do start screwing up, they stop. And back to this particular case, you've already indicated that you think justice was done; and as far as justice having been seen to be done, you can -- and have -- verified that yourself by looking at the mailing list archives and the bug log. We do have checks and balances -- the person affected can raise the issue on the mailing list for wide dispersal and discussion (exactly as happened), and other debbugs admins can overrule the decision if they think that's appropriate. We've got further checks and balances in the form of the tech ctte and GRs too. Given you agree with the outcome, I fail to see why you think that the existing checks and balances aren't enough. Your style, it seems to me--and *please* correct me where I misunderstand, don't just assume I'm wilfully trying to malign you--seems to be to demand that we must take it on faith that you are doing the right thing, and that you are not willing to open up your decisions to any kind of external examination. Even if you always make the right decisions unfailingly, I also want it to be transparent *that* they are the right decisions. I can't think how much more transparent you want than every conversation being logged and publically archived. I also find it pretty hard to give credence to your claim that this isn't personal when you're focussing so heavily on Your style, take it on faith that you are doing the right thing you are not willing to open up your decisions to any kind of external examination, if you always make the right decisions. Is it not a good thing to expect people to take responsibility for their actions? And we're back to snarky. Seriously, how attractive do you think it
Re: Question for candidate Towns
Anthony Towns aj@azure.humbug.org.au writes: Do you understand this trivially obvious thing? Obviously you don't, so here's a hint. is not being particularly polite -- it's showing off how smart you are and how dumb your correspondent is. Actually, it turns out we disagree about the thing in question, at a fairly fundamental level. So it's *not* trivially obvious, and I've learned an important fact about the way you judge potential conflicts of interest. For example, by just immediately explaining what you think the point of contention is, rather than trying to be cute about it. It's really not difficult. But often it is unclear what the point of contention *is* until people discuss freely what they think about it. Why am I the subject of this thread, rather than the subject being the issue of mailing list moderation? Because your platform said it was an important issue to you, and the other platforms do not. So it is very important to find out how you would seek to implement such a policy and what underlying ways you have about negotiating such things. I don't ask Branden (for example) the same question, because he hasn't announced any intention to clean up the mailing lists by potential moderation or exclusion or whatever else. I'll try your method. I have two bug reports open against ftp.debian.org. One was opened today, and Jeroen van Wolffelaar has helpfully worked with me about the mistakes I made in filing that one (for which I am grateful). The other, number 267494 has been open for 201 days, and was tagged confirmed by Jeroen van Welffelaar on September 25. What is the delay in processing 267494? It seems like it should take only a five-second rm command, but perhaps more is involved than that. Is further information necessary to determine how to process the bug correctly? (I'm interested in something more than we're working on other things; if you could say what those other things are that have been done and why they are higher priority, then I would understand.) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
also sprach Anthony Towns aj@azure.humbug.org.au [2005.03.11.0158 +0100]: I can't see any way of having polite reminders work without some sort of statement from the DPL or the listmasters, probably with the prospect of some sort of enforcement, though, personally. And I can't see how enforcement will fly within a project such as Debian. That said, there is no way to ban flamewars since they are sort of part of the nature of a project like this. There's a trivial way: moderate the lists. I think there are less fascist ways that'll be both effective and more efficient. But there's no point kidding ourselves that it'll be easy or that everyone'll be happy with the change. Let's try it. Let's create debian-devel-moderated and debian-user-moderated and see what happens. I volunteer to be (one of the) moderator(s). I am not trying to encourage or justify them; I just think that there should be no punishment for them in the way you propose. If you don't want the punishment, don't do the wrong thing :) Oh, is that how it works??? 8-] The story would be a different one if I did not feel like dak was a magic potion, the child of a few Debian developers who have been with the project very long, and who have gathered so much experience that I cannot even grasp the extent. There's nothing magic about anything in Debian; it's all just 1's and 0's. ... and a number of restricted machines, to name just one example of how people without access might feel excluded from the inner circle. I know the reason why these are restricted, which is mainly security. It's certainly not obscurity, but that's what is perceivable. I hope I am making sense. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Question for candidate Towns
martin f krafft [EMAIL PROTECTED] wrote: also sprach Anthony Towns aj@azure.humbug.org.au [2005.03.11.0158 +0100]: There's a trivial way: moderate the lists. I think there are less fascist ways that'll be both effective and more efficient. But there's no point kidding ourselves that it'll be easy or that everyone'll be happy with the change. Let's try it. Let's create debian-devel-moderated and debian-user-moderated and see what happens. I volunteer to be (one of the) moderator(s). Maybe trying is in fact the only way to know. When the german newsgroup de.comp.os.unix.linux.moderated was founded, I also preferred it over the unmoderated alternative, and I got better answers there. However, after a while the group nearly died - obviously posters preferred the faster (and, at least at the beginning, often wrong...) responses in the unmoderated group. But it might well be different, and we begin to estimate the quality of the moderated list. However, we should be careful not to make the problem worse instead of better: We don't gain much if anybody who wants to be informed then would have to follow -devel *and* -devel-moderated, -project *and* -project-moderated, and so on. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Question for candidate Towns
martin f krafft wrote: also sprach Martin Schulze [EMAIL PROTECTED] [2005.03.11.1222 +0100]: Which machines are you talking about? All those marked as restricted on db.debian.org. And of course, ftp-master.debian.org and security.debian.org :) So that was just a bogus comment to keep up the fire? ftp-master is copied on merkel, you can access without problems. security.debian.org doesn't have more information readable by developers than what is exposed via ftp and http. Which information are you missing in particular? The big picture -- like how it all plays together. The big picture is not hidden in restricted machines. They are restricted in order to reduce the chance to be compromised accidently. I am not trying to complain, just raise the point... And the point is what exactly? Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
also sprach Martin Schulze [EMAIL PROTECTED] [2005.03.11.1353 +0100]: And the point is what exactly? That people who would like to know more about Debian internals have no easy way of finding out, and if they approach those that know at the wrong time, or not in the way those would expect, they get flamed and blacklisted. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Question for candidate Towns
Joachim Breitner [EMAIL PROTECTED] schrieb: Hi, Am Freitag, den 11.03.2005, 13:14 +0100 schrieb Frank Küster: However, we should be careful not to make the problem worse instead of better: We don't gain much if anybody who wants to be informed then would have to follow -devel *and* -devel-moderated, -project *and* -project-moderated, and so on. Just forward all messages from -moderated to the regular list too, so that you either get only moderated messages (subscribed to -moderated), or get all messages (subscribed to the regular list). That does not help the people who a) want to be informed about -devel stuff (or -project stuff, or whatever) and b) would like to have a better S/N ratio on these lists. They would have to read the moderated list (with the good S/N ratio), but keep track of the unmoderated list as well. Well, they would have to do this *if* we are not careful to do it right. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Question for candidate Towns
martin f krafft wrote: also sprach Martin Schulze [EMAIL PROTECTED] [2005.03.11.1353 +0100]: And the point is what exactly? That people who would like to know more about Debian internals have no easy way of finding out, and if they approach those that know at the wrong time, or not in the way those would expect, they get flamed and blacklisted. As you weren't able to provide a single problem (but only listed a non-problem), I consider you're just a firefeeder. Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
martin f krafft wrote: also sprach Anthony Towns aj@azure.humbug.org.au [2005.03.11.0158 +0100]: I can't see any way of having polite reminders work without some sort of statement from the DPL or the listmasters, probably with the prospect of some sort of enforcement, though, personally. And I can't see how enforcement will fly within a project such as Debian. Ah, well, that's resolvable. The debian-release list enforcement policy of politely asking people to stay on topic has worked quite well and hasn't needed any augmentation. See, for instance: http://lists.debian.org/debian-release/2004/06/msg00071.html http://lists.debian.org/debian-release/2005/01/msg00036.html The get 0-day NMUs right enforcement policy of preventing people who get it wrong from doing any more NMUs for a while was enforced once, and didn't need to be enforced again. Javier dealt with the issue with pretty good grace. http://lists.debian.org/debian-devel/2003/08/msg01625.html Enforcement of the BTS policy gets a few more flames because it only happens when people are already being argumentative, and because it's not a policy people are very well aware of in advance. OTOH, an argument doesn't stop the policy being effective -- for instance the debate over Enrico's suspension didn't stop Bug#224742 from being properly closed, which was the point of the policy. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=224742 http://lists.debian.org/debian-devel/2003/12/msg01966.html One of the elements which does help mitigate the negative effects of enforcing these policies is having somewhere to redirect the discussion to; in the cases above, that was -devel. That makes cleaning up -devel a little harder, of course, since there's no obvious answer to the question of where people can have offensive/off-topic/whatever discussions instead. I expect it'll probably be necessary to have a debian-lists list of some sort to take care of (civil) discussion of how the lists are/should be managed; and I expect the question of what we should encourage for uncivil discussion will be a difficult one. Some of the options I can think of are just blog about it, or blog about it, but don't syndicate it to Planet Debian, or complain on IRC instead, or have a debian-flames list, that's moderated, and only accepts *really* good, vicious, hurtful flames. (I figure, if you're getting flamed on a moderated list with high standards for flamage, you can at least console yourself with the knowledge that you've made it into the big leagues...) I've no idea which of those would be best, or if there're other ideas that'd be better. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Anthony Towns aj@azure.humbug.org.au writes: Enforcement of the BTS policy gets a few more flames because it only happens when people are already being argumentative, and because it's not a policy people are very well aware of in advance. OTOH, an argument doesn't stop the policy being effective -- for instance the debate over Enrico's suspension didn't stop Bug#224742 from being properly closed, which was the point of the policy. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=224742 http://lists.debian.org/debian-devel/2003/12/msg01966.html I have a question about this one. Enrico was abusing the system (from the bug log, at least, I concur with that judgment). But is it a coincidence that he was sanctioned, and that you were the maintainer of the package whose BTS he was abusing? In other words, if someone does that to my package, do I get to say, if you continue to abuse the BTS this way, your access to the control bot will be removed? In other words, you have the power to revoke access to the control bot, and gee it sure came in handy when your package's BTS was being abused. But is that a special privilege that only your packages get? What about the rest of us? I admit, I'm confused here. On the one hand, I agree with both the assessment that Enrico was abusing the BTS, and with the imposed sanction. But it also sounds like you got to be victim, judge, and jailer, all at once. Do the rest of us get this nice streamlined process? If someone abuses the BTS on my package, do I have to convince anyone of the abuse before I get to sanction them from the BTS control bot, or do I have to go through someone else? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Thomas Bushnell BSG wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=224742 http://lists.debian.org/debian-devel/2003/12/msg01966.html I have a question about this one. Enrico was abusing the system (from the bug log, at least, I concur with that judgment). But is it a coincidence that he was sanctioned, and that you were the maintainer of the package whose BTS he was abusing? In other words, if someone does that to my package, do I get to say, if you continue to abuse the BTS this way, your access to the control bot will be removed? Hrm. I thought for sure I'd made that clear in that thread, but now I can't seem to find any evidence of it. Yes, you do; though you'll obviously need to find a BTS admin to implement it, and, well, know about it. Err, /debbugs hat. With the candidate hat on it's: I support the judgement of the bugs.d.o maintainers; if they collectively think it's a good idea to extend, revoke or change that policy, more power to them. Cheers, a at least my head stays warm j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Romain Francoise wrote: Anthony Towns aj@azure.humbug.org.au writes: The debian-release list enforcement policy of politely asking people to stay on topic has worked quite well and hasn't needed any augmentation. Isn't it because the RMs have been asking people to treat -release as a role address? If you discourage discussion on a list, it's bound to see less flames than general discussion lists. Err, I thought that was what I said...? Anyway, there *is* on-topic discussion on that list, see eg the thread beginning at: http://lists.debian.org/debian-release/2004/08/msg00381.html Obviously, though, that discussion is very limited in its scope. I guess for comparison, you could say the role for -devel is Action items for improving the Debian distribution to have it fall under a similar role sort of heading; though working out who's ultimately responsible would be trickier. For contrast, the role for -legal is far simpler to come up with (Helping maintainers and upstream understand licensing issues and come up with licenses that satisfy the DFSG); yet it gives even -devel a run for its money in the verbose and unproductive stakes. So, I think the key point is the discourage off-topic discussion aspect, not the role address point. YMMV, of course. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
* Anthony Towns [Sat, 12 Mar 2005 10:52:49 +1000]: http://lists.debian.org/debian-devel/2003/12/msg01966.html Hrm. I thought for sure I'd made that clear in that thread, but now I can't seem to find any evidence of it. I'm happy to do the same thing for any other maintainer who is being attacked by someone who's trying to use the BTS reopen command to force a maintainer to do things against their better judgement. That's from the link above. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Truth is the most valuable thing we have, so let's economize it. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Adeodato Sim [EMAIL PROTECTED] writes: * Anthony Towns [Sat, 12 Mar 2005 10:52:49 +1000]: http://lists.debian.org/debian-devel/2003/12/msg01966.html Hrm. I thought for sure I'd made that clear in that thread, but now I can't seem to find any evidence of it. I'm happy to do the same thing for any other maintainer who is being attacked by someone who's trying to use the BTS reopen command to force a maintainer to do things against their better judgement. That's from the link above. Yes, but this doesn't *quite* answer my question. The question is whether the bts people will make their own decision about anything, or just do whatever the maintainer says. See, the point is that in Anthony Towns' case, he didn't need to worry about any re-investigation of the question. Nobody would decide that he's being unreasonable, nobody would second-guess his technical judgement, nobody would do anything, b/c he had control over both parts of it. Now I think he made the right judgment here, but that isn't the question. The question is if *I* try this, will the bts people start looking into the case, and make their own judgment about whether my request is reasonable? In other words, will they simply exclude someone on my say-so, or will they conduct their own investigation? Thomas
Re: Question for candidate Towns
Thomas Bushnell BSG wrote: Adeodato Sim [EMAIL PROTECTED] writes: * Anthony Towns [Sat, 12 Mar 2005 10:52:49 +1000]: http://lists.debian.org/debian-devel/2003/12/msg01966.html Hrm. I thought for sure I'd made that clear in that thread, but now I can't seem to find any evidence of it. I'm happy to do the same thing for any other maintainer who is being attacked by someone who's trying to use the BTS reopen command to force a maintainer to do things against their better judgement. That's from the link above. L33t, I'm blind. Yes, but this doesn't *quite* answer my question. The question is whether the bts people will make their own decision about anything, or just do whatever the maintainer says. Of course they'll look over whatever bug you claim is being abused. I don't understand why you'd even imagine it'd be otherwise. See, the point is that in Anthony Towns' case, he didn't need to worry about any re-investigation of the question. Of course I didn't: I could already see it was the case, and I gave Enrico fair warning after which he continued reopening the bug. If you're in the same circumstances, you don't need to worry about getting checked over either. Nobody would decide that he's being unreasonable, nobody would second-guess his technical judgement, nobody would do anything, My technical judgement got a thorough going over on -devel, which is archived permanently and available from the above urls, and should my judgement have been found seriously wanting any of the other debbugs admins would have corrected it. That's all as it should be. Also, the above's getting pretty off-topic -- it's no longer about the DPL stuff, and it's not even about anything happening currently, and it's even getting kinda close to just being a random personal attack about events from a year ago -- focussing as it does on whether I, personally, get different standards to everyone else in the project and am thus by implication some sort of immoral tyrant -- rather than anything particularly technical (since after all you've explicitly agreed the right outcome was reached). It'd be easy to bring it back on topic -- either by moving it to -devel or -debbugs and making it be about the bugs.d.o policy and improving that; or by discussing it in the context of Debian mailing list policy. But you're not doing that, and I suspect the thought didn't even cross your mind that it'd be a good idea -- heck, it only barely crossed my mind, and I'm the one on the whole clean up the lists kick here. I think that's the main problem with Debian lists -- we're too much in the habit of just discussing things interminably and forgetting what the whole point was in the first place. I think we need something to help get us (back?) in the habit of focussed, technical discussions by default rather than aimless political dialogues. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
On Sat, Mar 12, 2005 at 04:01:12PM +1000, Anthony Towns wrote: Of course they'll look over whatever bug you claim is being abused. I don't understand why you'd even imagine it'd be otherwise. Well, there is a DPL candidate who has, with another role hat on his head, repeatedly claimed that members of a role team do not have any obligation whatsoever to do anything on their job besides hanging on to the role hat. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
martin f krafft wrote: also sprach Anthony Towns aj@azure.humbug.org.au [2005.03.03.1827 +0100]: usual flamewars be declared off topic and either having the thread killed or, if necessary, the poster suspended. I am not sure this is a good idea. First off, we're all about freedom, and what you suggest is more reminiscent of totalitarianism than freedom of speech. The debian-release mailing list has very specific guidelines for what's on-topic: namely, action items for release. That's proven, in my opinion, and I believe that of the current release managers, quite effective, and hasn't required any enforcement beyond polite reminders now and then. I don't know if polite reminders will be enough for other lists -- as your mail indicates, the idea that flamewars are varyingly unavoidable, necessary or good is fairly ingrained. If they *are* then that's great, I don't see any reason to do anything more than that if they are effective. If they're not, well, having usable lists is more important than having a debian.org soapbox for whatever you want to say. I can't see any way of having polite reminders work without some sort of statement from the DPL or the listmasters, probably with the prospect of some sort of enforcement, though, personally. I continue to hold my position that more communication from the delegates to the rest of the develoepers would probably solve the problem adequatly. I don't believe it's possible to separate these two issues: while delegates don't have the support of the project, it's very difficult to communicate with it. I suspect the converse is so obvious it doesn't even need stating. That said, there is no way to ban flamewars since they are sort of part of the nature of a project like this. There's a trivial way: moderate the lists. I think there are less fascist ways that'll be both effective and more efficient. But there's no point kidding ourselves that it'll be easy or that everyone'll be happy with the change. I am not trying to encourage or justify them; I just think that there should be no punishment for them in the way you propose. If you don't want the punishment, don't do the wrong thing :) The story would be a different one if I did not feel like dak was a magic potion, the child of a few Debian developers who have been with the project very long, and who have gathered so much experience that I cannot even grasp the extent. There's nothing magic about anything in Debian; it's all just 1's and 0's. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
also sprach Anthony Towns aj@azure.humbug.org.au [2005.03.03.1827 +0100]: If elected DPL I'd aim to remove the list problems by having delegates lead discussion of problems in their fields of expertise and having the This sounds like the delegates would inform the general public of problems; this is good. usual flamewars be declared off topic and either having the thread killed or, if necessary, the poster suspended. I am not sure this is a good idea. First off, we're all about freedom, and what you suggest is more reminiscent of totalitarianism than freedom of speech. I agree that flamewars are not stimulating (and I did apologise for and repent starting one recently). I continue to hold my position that more communication from the delegates to the rest of the develoepers would probably solve the problem adequatly. You are planning to address this, so we are looking at better times! That said, there is no way to ban flamewars since they are sort of part of the nature of a project like this. I am not trying to encourage or justify them; I just think that there should be no punishment for them in the way you propose. I think it's easy to avoid those sorts of flamewars by starting a thread with a patch instead of complaints, Not speaking for anyone but myself, I hold the following position: I would like to help out, and I am not the one not to get my hands dirty; I submit patches to various projects on a regular basis, but only if I can figure out where to start. I am well aware that I could spend a weekend to dive into the depths of dak, but I have not yet found the time or motivation to do so. The story would be a different one if I did not feel like dak was a magic potion, the child of a few Debian developers who have been with the project very long, and who have gathered so much experience that I cannot even grasp the extent. Maybe this issue is a psychological one on my end, but it seems to prevail with a bunch of other developers too. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
also sprach Anthony Towns aj@azure.humbug.org.au [2005.03.04.2118 +0100]: I think the communication issues are just a stand in for complaints of the underlying cause. If they weren't, I think the new.html page should be more of a solution ... not many people knew about it until recently. And there has not been a flame war since it became widely public. The communication isn't perfect, but I don't think making it perfect would actually be a significant improvement. It would be an improvement on psychological level to some of the developers, which I think should not be underestimated. No, this is a policy problem. Communication is easy: hit M for manual reject, write a note, and it's all done. Or hit P for prod to write a note to the maintainer with the possibility of accepting the package anyway, or leaving it in the queue for later reconsideration. The issue for packages like mplayer and hot-babe is that it's not clear that they can be accepted, but it's also not clear that they should be rejected. And until one or the other becomes clear, they're left in the queue. Would it be conceivable to have e.g. a page per package in NEW where links and notes and comments can be collected, for everyone to be able to see? Sort of like the bug tracking system? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Question for candidate Towns
ke, 2005-03-09 kello 17:07 +0100, Michael Banck kirjoitti: On Wed, Mar 09, 2005 at 03:15:11PM +0100, martin f krafft wrote: That said, there is no way to ban flamewars since they are sort of part of the nature of a project like this. I do not subscribe to this. Flamewars are *not* a necessary evil (or even a good thing), I believe we would be at least as productive without them. The Python newsgroup (and corresponding list) comp.lang.python has always seemed to me much friendlier than Debian lists, despite the fact that they are of similar sizes. I claim therefore it is possible to have a big group of people working and talking together even about controversial issues without flames, if the group as a whole considers it a good thing and there are prominent role models that eschew flames and actively calm things down when they get hot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Mon, Mar 07, 2005 at 06:56:44PM -0600, Adam Heath wrote: On Sat, 5 Mar 2005, Sven Luther wrote: On Fri, Mar 04, 2005 at 01:59:16PM -0800, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: I have some real trouble with the fact that all the work i do for debian is reported to the US secret services or whatever by the ftp-masters and our archive handling services, and i certainly did *NOT* agree to this being the case. What are you talking about? Debian prohibits anonymous developers, always has; for the longest time this was the only real restriction on joining Debian: you had to find a few other Debian developers to verify you had a real ID. Yep, but there is a difference between the information being available, and it being actively feeded to the NSA or whoever. And it is especially bothering if this cause undue delay in our normal activities, like aj is saying it is. So, you want to abolish the DFSG? What part of free do you not understand? Notice that : 1) to have a package pass NEW, some manual BSwhatevr notification is needed. 2) this means that we are not free to do a modification of a package that makes it go into NEW without the approval of the ftp-master *and* the notification to said agency. 3) Some would argue that this impose an additional fee or restriction (in the same way as a post-card licence) on our distribution as part of debian. (read the debian-legal posts for this past year or so, if you doubt). 4) furthermore, i believe that, altough it never happened, it could well be that the BSwhatever agency may also once it reads the notification, reject the export authorization for a particular package, no ? So, you want to go into DFSG flamewar, please go ahead. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
On Mon, Mar 07, 2005 at 09:53:52AM -0800, Anthony Towns wrote: Eduard Bloch wrote: Sorry, I did not follow the threads from the beginning, but... whom should I believe? I inteprett your answers as exactly what Henning describes. What I miss is a clear statement: - what is going wrong - why is it going wrong Uh, what are you talking about? NEW processing? For example, there is no excuse for blocking libs because of obvious soname changes in new, for months now. They're not blocked, they're just not being done. The answers to your question are either NEW is not being processed / because people don't have the time to do it, or People don't have enough time / because we've got a release to get out and in general, that's just the way life is depending on what you were asking. There's nothing more to it than that. And when the release depends on testing of packages which in turn is blocked by the upload to NEW, which in turn is not being done because people are working on the release, which ... Nice circular depenendy problem :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Anthony Towns aj@azure.humbug.org.au wrote: Frank Küster wrote: With that hat on, this statement is perfectly acceptable, just as all the mails you sent about NEW processing. The problem, to me, is that you fail to see the issue from a different side, and you definitely *should* as a DPL candidate. As a DPL candidate, you should not only care about how delegates do their work. You should also care about how this work is communicated to the other developers, and how the other developers perceive this work. If you don't think I'll behave as well as another candidate, please rank me below that person. That's fine, that's the way this is meant to work. As far as I understood, the campaigning period is also meant to communicate one's opinion about different candidates to other developers. This is what I did. If you're asking me what I think about how delegates to their work; well, I thought I'd already covered this, but to reiterate: I think by and large all our delegates are doing a good job, and the most effective assistance they could get is support from the project for their work, and the best way to to improve communication of what's going on is to ensure such communication is welcomed wholeheartedly, not by a That's great, but response including a treatise on how else they're unsatisfactory. It seems that many people try to communicate with the ftpmaster team, and get the feeling that this communication is not welcomed at all, if ever read. Whether this is correct or not does not matter; the feeling is there and has a bad influence on how they work, and how they interact with the ftpmaster team. Obviously, the ftpmasters' work is perceived as problematic by DD's (problematic for them, and for the project). If you're not perceiving things in a way that matches reality, the problem's your own, not anyone else's. Right. But I don't talk of the reality of how the ftpmaster team does their job, but of the reality of how a large subgroup of developers perceive this work (and act/flame/... accordingly). This is some sort of reality, too, with considerable impact on the work of the project. Hrm, you know, that's enough about NEW and ftpmaster from me. If my views are really that unclear, or otherwise require further exploration, how about an original example? Your problem seems to be that you believe you know what the reality is. You're not wrong, but you're not right either - obviously there are more than one reality here. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Sven Luther wrote: It's hard to take this sort of discussion as anything but an attack on ftpmaster, since there are plenty of teams in Debian that're even less transparent and effective than us. But given how these sorts of But they are less a hindrance to the daily work of maintainers, and can thus more easily be avoided/worked around/whatever. If you think ftpmaster is a hindrance to your daily work, it's trivial to avoid it -- upload to your own site instead, or to people.debian.org. Given I personally worked around the lack of ftpmaster support for pools for a good six to twelve months while developing testing, I think I've got a reasonable basis for thinking this isn't such a big deal. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Sven Luther wrote: On Mon, Mar 07, 2005 at 06:56:44PM -0600, Adam Heath wrote: 4) furthermore, i believe that, altough it never happened, it could well be that the BSwhatever agency may also once it reads the notification, reject the export authorization for a particular package, no ? No. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Anthony Towns aj@azure.humbug.org.au wrote: Sven Luther wrote: It's hard to take this sort of discussion as anything but an attack on ftpmaster, since there are plenty of teams in Debian that're even less transparent and effective than us. But given how these sorts of But they are less a hindrance to the daily work of maintainers, and can thus more easily be avoided/worked around/whatever. If you think ftpmaster is a hindrance to your daily work, it's trivial to avoid it -- upload to your own site instead, or to people.debian.org. That is no solution. To me, Debian work does not mean just to create fancy packages, used by a couple of geeks who work with a huge sources.list. Rather, it means providing an operating system for users who want a sources.list as small as possible, perhaps only their CDs and security. Given I personally worked around the lack of ftpmaster support for pools for a good six to twelve months while developing testing, I think I've got a reasonable basis for thinking this isn't such a big deal. This work wasn't targetted at users at that stage, was it? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Question for candidate Towns
Anthony Towns aj@azure.humbug.org.au wrote: Well, here's a simple train of thought: (1) Hrm, ftpmaster aren't doing things as quickly as normal. (2) Gosh, that probably means they're really busy. (3) I wonder what I could do that would help. Here's a train of thought that doesn't work so well: (1) Hrm, ftpmaster aren't doing things as quickly as normal. (2) Not that that's very quick anyway. (3) Why the hell isn't there an explanation somewhere about the change somewhere? (4) Oh, that's right, because they're in the Cabal and don't care about us peons. Bastards. (5) GAR! What can I do to make them hurry up and do what I want? Here's third one: (1) Hrm, ftpmaster aren't doing things as quickly as normal. (2) Not that that's very quick anyway. (3) Why the hell isn't there an explanation somewhere about the change somewhere? (4) What could we do to get the information? (4a) Let's ask on -devel == here we go, an other flamewar (4b) - I don't know what a better 4b could be. I've no grudge against ftpmaster. Then how about doing the courtesy of not using ftpmaster as a perfect opportunity to discuss inadequate teams? What I, and as I understand it also others, try to discuss is not inadequate teams, but inadequate flow of information inside the Debian Project. Which is a topic that should _not_ be addressed at the ftpmaster team - but seems well addressed at a DPL candidate who has experience with the team that currently is one of the points where this missing flow of information shows up. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Tue, Mar 08, 2005 at 06:12:03AM -0800, Anthony Towns wrote: Sven Luther wrote: It's hard to take this sort of discussion as anything but an attack on ftpmaster, since there are plenty of teams in Debian that're even less transparent and effective than us. But given how these sorts of But they are less a hindrance to the daily work of maintainers, and can thus more easily be avoided/worked around/whatever. If you think ftpmaster is a hindrance to your daily work, it's trivial to avoid it -- upload to your own site instead, or to people.debian.org. And hack debian-installer to by default get powerpc kernels out of a personal archive ? I almost did that when NEW processing disintegrated two years ago during the compromise, but i don't think this is compatible with the release-management work surrounding the d-i. As a result of 1 and a half month waiting in processing the kernel-latest-powerpc metapackage for example, we will not have support for it in d-i rc3, for example, and thus future upgrades of kernels installed with it will be problematic. Given I personally worked around the lack of ftpmaster support for pools for a good six to twelve months while developing testing, I think I've got a reasonable basis for thinking this isn't such a big deal. It depends on what you want to do, if you just want to do your own stuff in your corner, well, it is possible, or if you do an experiment like you did, but if your packages aim to be part of the of the release, having it outside the archive is not helping. And we will soon upload 2.6.11 kernels, which will mean handling of N+1 NEW packages, where N is the number of architectures supporting the 2.6 kernels. This could easily enough be automated, and i don't think the NEW reporting to the US agencies needs to go done to the level of renamed binary packages or new versions of basically the same thing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Tue, Mar 08, 2005 at 06:09:00AM -0800, Anthony Towns wrote: Well, here's a simple train of thought: (1) Hrm, ftpmaster aren't doing things as quickly as normal. (2) Gosh, that probably means they're really busy. (3) I wonder what I could do that would help. Ah, well, in how can we help the ftp-masters ? As a maintainer, the only way to help on this would be to send some kind of explanation of why a previously existing package changed and thus got need of NEW handling. There is no evidence that this message get read, is indeed a help to ftp-master, or just plain lost time on the maintainer's side. Right now the only way to help is to get hold of a ftp-master on irc and bug him about your own individial package in NEW, or get someone else with more prestige or whatever to do the bugging for you. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Frank Küster wrote: Given I personally worked around the lack of ftpmaster support for pools for a good six to twelve months while developing testing, I think I've got a reasonable basis for thinking this isn't such a big deal. This work wasn't targetted at users at that stage, was it? I was using it for almost that entire period [0] -- eat your own dog-food and all. It was available to users for that period too, I've no idea how commonly it was used -- we were frozen and preparing the potato release for the majority of that time [1]. I was certainly trying to make it useful for users at the time. Cheers, aj [0] http://lists.debian.org/debian-project/1999/12/msg00031.html http://lists.debian.org/debian-project/2000/02/msg0.html http://lists.debian.org/debian-devel-announce/2000/12/msg00011.html [1] http://lists.debian.org/debian-devel-announce/2000/01/msg00013.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Anthony Towns aj@azure.humbug.org.au schrieb: Frank Küster wrote: Given I personally worked around the lack of ftpmaster support for pools for a good six to twelve months while developing testing, I think I've got a reasonable basis for thinking this isn't such a big deal. This work wasn't targetted at users at that stage, was it? [...] I was certainly trying to make it useful for users at the time. But you were not working on boot-floppies, or d-i as it would be now. And while it might have been okay for some users to add this line to their sources.list, it is my strong believe that such an approach, generally taken, would do Debian strong harm. We would degenerate to a group discussing and proposing a policy document, with many nearly or hardly policy-compliant repositories growing around us. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Question for candidate Towns
Henning Makholm wrote: Scripsit Anthony Towns aj@azure.humbug.org.au Matthew Garrett wrote: (I'm not suggesting that the ftp-masters are doing their job inadequately here, See, that's the thing, you _are_. You can tell, because you had to explicitly refute the idea; it's the same as being able to tell you're being offensive when you feel the need to say no offense intended. No. He had to explicitly refute the idea because you're famous for consistently interpreting *any* suggestion that something in our organisation might not work optimally and needs improvement as if it was a personal attack on whomever is currently responsible for that particular something. I don't believe that's the case. As a counter example, I offer http://lists.debian.org/debian-devel/2005/01/msg00671.html It's quite possible to talk about technical issues without blaming people or suggesting they're incompetent or that they ought to be doing their job better. And sometime's that's necessary; but it's happening _continually_, which is just tiresome and demotivating. What's extremely demotivating is your continued insistence that everybody who want to improve something is attacking the people who are involved in the something that could be improved. *shrug* If you'd like to help, you need to stop talking and listen: what I've been saying for over a year now is the best thing that could be done to improve the groups I know of is to stop the flaming and blaming. If you're not willing to do that, that's fine, but don't act surprised when things don't improve, or when you get ignored when you ask for information so that you can help. Maybe other people can think of better ways of improving things, but to my mind, that one's at least an order of magnitude more important than anything else at encouraging people to do work and to participate in discussions. As in: The first step in improving something is to find out more about what the problem is. The way to learn about what the problem is is to ask on an appropriate mailing list. So, there's your answer. Does it make you happy, or does it just annoy you? Whenever one asks what the problem is, Anthony Towns will immediately reinterpret the question as being offense and an accusation that the problem is that the current delegates are not doing their job properly. This instantly turns the initial problem-solving attempt into an unproductive flamewar. It takes two to have a flamewar. Are you really so invested in comments like You're famous for consistently interpreting *any* suggestion as if it was a personal attack that giving them up isn't even worth considering? Do you have a better term for the above quote than a personal attack, btw? This is probably going to happen no matter who we elect for DPL, but I cannot begin to imagine the chilling effect it would have if Anthony Towns were also the DPL, who in his campaign have asserted that being offensive should lead the one asking the question to be suspended, banned, or removed from the project entirely. [http://lists.debian.org/debian-vote/2005/03/msg00075.html] I'm pretty confident I can find someone who's not me to enforce that policy who doesn't suffer from that level of infamy, and I'm also pretty confident that given that policy being actually enforced, that I can encourage a bunch of people who currently aren't interested in participating in the lists to change their view. You're, of course, welcome to believe that or not, as you see fit. And given we just had this _exact_ flamewar a month ago on -project, along with similar ones at least every month or so for years now, I don't really see any evidence for there being a chilling effect. But hey, YMMV. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Sun, Mar 06, 2005 at 03:02:34PM +, Matthew Garrett wrote: Anthony Towns aj@azure.humbug.org.au wrote: I actually think that's a good result: far better to keep track of the problematic packages, than to just REJECT them with a reason like doesn't seem like a good idea and have them randomly reuploaded later. It also seems like a better idea to let packages that don't seem like a good idea sit in the queue, rather than get uploaded and distributed around the world. I'm certainly not suggesting that they be rejected out of hand, and accepting them isn't the correct decision either. Currently, though, it's impossible to tell the difference between This package is awkward and This package is being ignored. Making the distinction explicit causes little harm. Especially when the maintainer uploading the packages is *not* made aware of the fact that the package is awkward, and any input he may provide to making it less awkward is just plainly ignored. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
#include hallo.h * Anthony Towns [Mon, Mar 07 2005, 12:34:02AM]: I'm pretty confident I can find someone who's not me to enforce that policy who doesn't suffer from that level of infamy, and I'm also pretty confident that given that policy being actually enforced, that I can encourage a bunch of people who currently aren't interested in participating in the lists to change their view. You're, of course, welcome to believe that or not, as you see fit. Sorry, I did not follow the threads from the beginning, but... whom should I believe? I inteprett your answers as exactly what Henning describes. What I miss is a clear statement: - what is going wrong - why is it going wrong Maybe some status page in wiki.debian.org (refered in your signature) would help much more than you think. Without any clue, one can only follow the reasoning in polemic mails and you are (personal opinion) not really good at fighting back. For example, there is no excuse for blocking libs because of obvious soname changes in new, for months now. It is really not understandable, it annoys people because their work gets stuck because someone is insert reason to copypaste few lines to another file to allow some dependency to be accepted. This is really not understandable. OTOH I doubt that you can realize that - when did YOU submit YOUR last _new_ package and had to wait two months? Regards, Eduard. -- meebey köstlich * meebey schlürft gerade selbstgemachten Swimming Pool Cocktail Moermel meebey: Wasser+Harnstoff? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Op vr, 04-03-2005 te 21:09 +0100, schreef Sven Luther: On Fri, Mar 04, 2005 at 11:07:06AM -0800, Anthony Towns wrote: Kalle Kivimaa wrote: Anthony Towns aj@azure.humbug.org.au writes: resolves the complaints about NEW and hence I don't think that the NEW issue is an example of a communication problem at all. This is getting slightly too detailed discussion for a DPL, but anyway: what do you think the NEW issue is an example of? Not having enough time in the day. The resolutions to that are: (a) reprioritising things (b) making more time available (c) making things take less time (d) training other people What about (e) automating tasks which don't really need human intervention ? Oh, come on. That falls in (c), making things take less time. If you're willing to code up the support for that, the code for dak is in public CVS. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Sun, Mar 06, 2005 at 11:28:57AM -0800, Anthony Towns wrote: There's no particular reason NEW isn't being processed -- people are just busy doing other things; some of which are outside Debian, others of which are related to getting the release out, or whatever else. That's not, in my opinion, something Debian developers have any right to ask for -- my day planner's my business, not yours. Yes and no. I think that the developers have no right to expect that any particular ftp-master (or other role) will commit any particular time or amount of time. But we should expect that the ftp-master group as a whole will accomplish its appointed tasks, which includes processing NEW packages. If there are insufficient ftp-master-hours to keep the backlog to a reasonable limit then additional ftp-masters should be trained. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
On Mon, Mar 07, 2005 at 12:52:51PM +0100, Wouter Verhelst wrote: Op vr, 04-03-2005 te 21:09 +0100, schreef Sven Luther: On Fri, Mar 04, 2005 at 11:07:06AM -0800, Anthony Towns wrote: Kalle Kivimaa wrote: Anthony Towns aj@azure.humbug.org.au writes: resolves the complaints about NEW and hence I don't think that the NEW issue is an example of a communication problem at all. This is getting slightly too detailed discussion for a DPL, but anyway: what do you think the NEW issue is an example of? Not having enough time in the day. The resolutions to that are: (a) reprioritising things (b) making more time available (c) making things take less time (d) training other people What about (e) automating tasks which don't really need human intervention ? Oh, come on. That falls in (c), making things take less time. Only if you aknowledge there is need for it, but i haven't seem that happen, not in this thread, not in previous discussions about the subject. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Frank Küster wrote: With that hat on, this statement is perfectly acceptable, just as all the mails you sent about NEW processing. The problem, to me, is that you fail to see the issue from a different side, and you definitely *should* as a DPL candidate. As a DPL candidate, you should not only care about how delegates do their work. You should also care about how this work is communicated to the other developers, and how the other developers perceive this work. If you don't think I'll behave as well as another candidate, please rank me below that person. That's fine, that's the way this is meant to work. If you're asking me what I think about how delegates to their work; well, I thought I'd already covered this, but to reiterate: I think by and large all our delegates are doing a good job, and the most effective assistance they could get is support from the project for their work, and the best way to to improve communication of what's going on is to ensure such communication is welcomed wholeheartedly, not by a That's great, but response including a treatise on how else they're unsatisfactory. Obviously, the ftpmasters' work is perceived as problematic by DD's (problematic for them, and for the project). If you're not perceiving things in a way that matches reality, the problem's your own, not anyone else's. Hrm, you know, that's enough about NEW and ftpmaster from me. If my views are really that unclear, or otherwise require further exploration, how about an original example? Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Scripsit Anthony Towns aj@azure.humbug.org.au Matthew Garrett wrote: (I'm not suggesting that the ftp-masters are doing their job inadequately here, See, that's the thing, you _are_. You can tell, because you had to explicitly refute the idea; it's the same as being able to tell you're being offensive when you feel the need to say no offense intended. No. He had to explicitly refute the idea because you're famous for consistently interpreting *any* suggestion that something in our organisation might not work optimally and needs improvement as if it was a personal attack on whomever is currently responsible for that particular something. And sometime's that's necessary; but it's happening _continually_, which is just tiresome and demotivating. What's extremely demotivating is your continued insistence that everybody who want to improve something is attacking the people who are involved in the something that could be improved. As in: The first step in improving something is to find out more about what the problem is. The way to learn about what the problem is is to ask on an appropriate mailing list. Whenever one asks what the problem is, Anthony Towns will immediately reinterpret the question as being offense and an accusation that the problem is that the current delegates are not doing their job properly. This instantly turns the initial problem-solving attempt into an unproductive flamewar. This is probably going to happen no matter who we elect for DPL, but I cannot begin to imagine the chilling effect it would have if Anthony Towns were also the DPL, who in his campaign have asserted that being offensive should lead the one asking the question to be suspended, banned, or removed from the project entirely. [http://lists.debian.org/debian-vote/2005/03/msg00075.html] -- Henning Makholm I Guds Faders namn, och Sonens, och den Helige Andes! Bevara oss från djävulens verk och från Muhammeds, den förbannades, illfundigheter! Med dig är det värre än med någon annan, ty att lyssna till Muhammed är det värsta av allt.
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
* Sven Luther ([EMAIL PROTECTED]) [050305 09:00]: On Fri, Mar 04, 2005 at 01:59:16PM -0800, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: I have some real trouble with the fact that all the work i do for debian is reported to the US secret services or whatever by the ftp-masters and our archive handling services, and i certainly did *NOT* agree to this being the case. What are you talking about? Debian prohibits anonymous developers, always has; for the longest time this was the only real restriction on joining Debian: you had to find a few other Debian developers to verify you had a real ID. Yep, but there is a difference between the information being available, and it being actively feeded to the NSA or whoever. The information is feed to the BXA, not to the NSA. But even worse for you, much more detailed information is feeded to me every day - and I really read them even. 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: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Sat, Mar 05, 2005 at 08:48:21AM +0100, Sven Luther wrote: On Fri, Mar 04, 2005 at 01:59:16PM -0800, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: I have some real trouble with the fact that all the work i do for debian is reported to the US secret services or whatever by the ftp-masters and our archive handling services, and i certainly did *NOT* agree to this being the case. What are you talking about? Debian prohibits anonymous developers, always has; for the longest time this was the only real restriction on joining Debian: you had to find a few other Debian developers to verify you had a real ID. Yep, but there is a difference between the information being available, and it being actively feeded to the NSA or whoever. The NSA subscribing to d-d-changes would also mean we are actively feeding information to them. And the info doesn't get sent to the NSA, as has been mentioned whenever you come up with this paranoid claptrap. And it is especially bothering if this cause undue delay in our normal activities, like aj is saying it is. WTF? I must have missed that one. So far, I've only seen aj mention that packages that are troublesome but not grossly rejectable tend to hang around in the queue. I can't imagine that sending a quick e-mail to the BXA is the holdup. Furthermore, sure there are no anonymous debian developer, but still the real identity is known only to debian, so theoretically we could hide it from the outside if we wanted. This makes no sense. Do you propose that we replace the name and e-mail address of every DD in every location where they exist (mailing lists, package control files, and so on) with a pseudonym and e-mail alias? Not to mention the fact that we're trying to increase transparency, not hand out secret rings to DDs and swear them to secrecy... - Matt signature.asc Description: Digital signature
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Sven Luther [EMAIL PROTECTED] writes: Yep, but there is a difference between the information being available, and it being actively feeded to the NSA or whoever. And it is especially bothering if this cause undue delay in our normal activities, like aj is saying it is. Tough. It's *public*. Anyone could actively feed it to anyone they like. What part of public don't you understand? You want it public, but for nobody to feed it to people you dislike? Good grief. Furthermore, sure there are no anonymous debian developer, but still the real identity is known only to debian, so theoretically we could hide it from the outside if we wanted. Our policy is the opposite, or hadn't you noticed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Sat, Mar 05, 2005 at 09:02:36AM +0100, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [050305 09:00]: On Fri, Mar 04, 2005 at 01:59:16PM -0800, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: I have some real trouble with the fact that all the work i do for debian is reported to the US secret services or whatever by the ftp-masters and our archive handling services, and i certainly did *NOT* agree to this being the case. What are you talking about? Debian prohibits anonymous developers, always has; for the longest time this was the only real restriction on joining Debian: you had to find a few other Debian developers to verify you had a real ID. Yep, but there is a difference between the information being available, and it being actively feeded to the NSA or whoever. The information is feed to the BXA, not to the NSA. But even worse for you, much more detailed information is feeded to me every day - and I really read them even. So what ? You are one of us, and not a potentially hostile outside agency. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Fri, Mar 04, 2005 at 01:55:25PM -0800, Anthony Towns wrote: Sven Luther wrote: I have some real trouble with the fact that all the work i do for debian is reported to the US secret services or whatever by the ftp-masters and our archive handling services, and i certainly did *NOT* agree to this being the case. Everyone subscribed to debian-devel-changes gets notified of every change you make; and we certainly welcome everyone to subscribe to that, including the US export bureau or secret service. That we happen to provide a slightly briefer summary for the BXA doesn't really change that in any way. In fact, the summary excludes the names of package maintainers as well as other information that gets posted to -devel-changes. Yeah, ok, but then how does this interact with automated NEW processing for not-really-NEW packages ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
NEW processing and crypto notification (was: Re: Question for candidate Towns)
On Saturday 05 March 2005 10:59, Sven Luther wrote: On Fri, Mar 04, 2005 at 01:55:25PM -0800, Anthony Towns wrote: Sven Luther wrote: I have some real trouble with the fact that all the work i do for debian is reported to the US secret services or whatever by the ftp-masters and our archive handling services, and i certainly did *NOT* agree to this being the case. Everyone subscribed to debian-devel-changes gets notified of every change you make; and we certainly welcome everyone to subscribe to that, including the US export bureau or secret service. That we happen to provide a slightly briefer summary for the BXA doesn't really change that in any way. In fact, the summary excludes the names of package maintainers as well as other information that gets posted to -devel-changes. Yeah, ok, but then how does this interact with automated NEW processing for not-really-NEW packages ? As ajt said in http://lists.debian.org/debian-vote/2005/03/msg00104.html: | It's not a technical issue it's a legal one -- our approach to satisfying | the legal requirements for including crypto software in main require us to | manually process each package with a new name. Yes, it really is necessary. Searching through my d-d-a archive I found: http://www.debian.org/legal/cryptoinmain Somewhere in the middle of the document it details, that a written notice _on paper_ has to be sent to the NSA. But instead of rehashing well known points, Sven could compile a public(!) list of packages needing processing from http://ftp-master.debian.org/new.html with explanations and pointers why which action should be taken on them. I am sure, a research robot (like Martin Schulze for stable point releases) would be able to add valuable input to NEW processing. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Fri, Mar 04, 2005 at 12:18:37PM -0800, Anthony Towns wrote: Matthew Garrett wrote: 3) My package has been sitting in the queue for ages and other packages have been processed This is a communication problem. No, this is a policy problem. Communication is easy: hit M for manual reject, write a note, and it's all done. Or hit P for prod to write a note to the maintainer with the possibility of accepting the package anyway, or leaving it in the queue for later reconsideration. The issue for packages like mplayer and hot-babe is that it's not clear that they can be accepted, but it's also not clear that they should be rejected. And until one or the other becomes clear, they're left in the queue. I actually think that's a good result: far better to keep track of the problematic packages, than to just REJECT them with a reason like doesn't seem like a good idea and have them randomly reuploaded later. It also seems like a better idea to let packages that don't seem like a good idea sit in the queue, rather than get uploaded and distributed around the world. I think there are actually five outcomes (or more) but only two of them are currently communicated: 1. Accepted; 2. Rejected; 3. Delayed because we're real busy but we'll get to it; 4. Delayed because we're not sure what to do with it (mplayer etc); 5. Delayed because we've stopped processing NEW to concentrate on another issue (like testing-security or the release or whatever). The latter three don't get communicated currently. There's rumours on debian-devel that NEW processing is actual on hold (by decision rather than by default) but that wasn't communicated. Of course it may be false and I don't expect to ftp-masters to have to refute every silly rumour, but some sign of life with regard to NEW processing would also be a positive sign. My example is the gEDA packages, which consists of a library and a bunch of apps distributed as separate source tarballs but always released together. New upstream versions almost always change the library soname due to API changes, and I've always reflected the soname in the binary package name, which then requires NEW processing. The package has been stuck in incoming for 2 months now. I asked for suggestions on a better approach on debian-devel, but the only replies I got told me that I must follow the letter of policy regardless of the circumstances. This relates to the better quality packaging you were talking about too. In the end I rearranged the packaging so that the NEW package wasn't needed, though I might be violating the letter of policy now. Just to avoid NEW processing delays each time. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Is NEW processing on hold? (was: Question for candidate Towns)
Hamish Moffatt [EMAIL PROTECTED] wrote: There's rumours on debian-devel that NEW processing is actual on hold (by decision rather than by default) but that wasn't communicated. Of course it may be false It is false. http://lists.debian.org/debian-devel-changes/2005/03/msg00019.html Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Sven Luther [EMAIL PROTECTED] writes: So what ? You are one of us, and not a potentially hostile outside agency. PUBLIC. That means not only to us, but to hostile things too. Hostile things like the US Government, or *really* hostile things like the governments of France and China. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Thu, Mar 03, 2005 at 11:33:43PM -0800, Anthony Towns wrote: Sven Luther wrote: On Thu, Mar 03, 2005 at 09:27:36AM -0800, Anthony Towns wrote: Steve Langasek wrote: As someone who is both an ftpmaster and a DPL candidate, could you also tell us what resources you (or the ftpmasters as a group, if you believe it's appropriate to speak for them) would appreciate? The most valuable thing I can think of would be to not have to have some flame or another continually burning on the lists about how ftpmaster Well, you seem to mention mostly the flames, Yes, because the question asked was what could be done to allow ftpmaster to act more effectively; not what things we would like to do more effective I understand that flames are entirely out of order, Flames aren't entirely out of order, least of all if you use the term like I do to encompass a pretty wide range of passionate debate. The problem comes when flaming is the order of the day, rather than a special event. And that applies even if the flame is just a fairly polite statement that you're not doing the job in the way I expect you to. Well, i guess people get rather irritated if sending email to ftp-master email address for things that are mostly reasonable could as well go to /dev/null, so i guess it is mostly a communication problem. You wouldn't accept this kind of behavior from DDs on their package maintenance, but it is perfectly normal for the ftp-masters to do it ? And it is worse since the email don't come from random users, but from the exact same DDs who are all working together to make it all happen. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Sven Luther wrote: Well, i guess people get rather irritated if sending email to ftp-master email address for things that are mostly reasonable could as well go to /dev/null, Sure, of course they are, and so they should be. I can fairly readily find 52k more reasons for people to be irritated with Debian too, the most recent numbered 298050. I'm pretty sure I could come up with some more beyond that too. so i guess it is mostly a communication problem. But that's not really true either, in my opinion. The issue isn't whether you get a mail back saying Thankyou for your letter, you have been placed in a priority queue, you are currently at position #548. Please hold. Tralalalalalala. -- it's whether things get done: whether NEW gets processed, removals get done, sections get updated, support for new architectures, features, packages, whatever get implemented. As a concrete example, I don't think http://ftp-master.debian.org/new.html resolves the complaints about NEW and hence I don't think that the NEW issue is an example of a communication problem at all. You wouldn't accept this kind of behavior from DDs on their package maintenance, That's not true. Plenty of DDs are non-responsive for one reason or other, and it's perfectly acceptable; we even have documented procedures to deal with that -- NMUs, vacation reports, and QA among other things. It's completely acceptable for volunteers to spend their time how they see fit, prioritising the work they think's most important, or prioritising other parts of their life over Debian if they think that's important. That's not to that I don't think it's worth improving this and finding ways to encourage people to commit more time to Debian or to use that time more effectively; and for this particular case I've already described what activity I think would lead to the biggest improvement. but it is perfectly normal for the ftp-masters to do it ? Meanwhile, I think claims like You wouldn't accept this from normal people, but it's standard procedure for ftpmaster are likely to simply exacerbate the problem. YMMV, of course, and if it does, you might well be right while I'm wrong. Whatever experience I have might provide a better basis for my judgements to rest upon than yours have; or it might mean I'm too close to the problem and completely off-track. And it is worse since the email don't come from random users, but from the exact same DDs who are all working together to make it all happen. Ideally all requests from everybody would be acted upon quickly and effectively; but that's not feasible, so they get prioritised. Taking developers more seriously than users, or release managers more seriously than developers are just two variants of the same prioritisation scheme, so I don't think it's worse at all. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
Anthony Towns aj@azure.humbug.org.au writes: resolves the complaints about NEW and hence I don't think that the NEW issue is an example of a communication problem at all. This is getting slightly too detailed discussion for a DPL, but anyway: what do you think the NEW issue is an example of? -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Fri, Mar 04, 2005 at 03:29:58AM -0800, Anthony Towns wrote: Sven Luther wrote: Well, i guess people get rather irritated if sending email to ftp-master email address for things that are mostly reasonable could as well go to /dev/null, Sure, of course they are, and so they should be. I can fairly readily find 52k more reasons for people to be irritated with Debian too, the most recent numbered 298050. I'm pretty sure I could come up with some more beyond that too. so i guess it is mostly a communication problem. But that's not really true either, in my opinion. The issue isn't whether you get a mail back saying Thankyou for your letter, you have been placed in a priority queue, you are currently at position #548. Please hold. Tralalalalalala. -- it's whether things get done: whether NEW gets processed, removals get done, sections get updated, support for new architectures, features, packages, whatever get implemented. Yeah, but it would be nice to get at least a little notice when you send a nice email to ftp-masters asking to please get a NEW processing for a given package since it is *NEEDED* for the d-i rc3 deadline which is approaching fast. Complete silence is in my opinion not in order on this. And there is clearly a subgroup of people who know how to approach the ftp-masters through irc to accelerate the processing. But i don't think this should be the canonical approach to this. As a concrete example, I don't think http://ftp-master.debian.org/new.html resolves the complaints about NEW and hence I don't think that the NEW issue is an example of a communication problem at all. I on the contrary think so, the above is nice though and i didn't knew about this, but communication goes both ways. You wouldn't accept this kind of behavior from DDs on their package maintenance, That's not true. Plenty of DDs are non-responsive for one reason or other, and it's perfectly acceptable; we even have documented procedures to deal with that -- NMUs, vacation reports, and QA among other things. Ok, so you advocate NMUing the ftp-masters on NEW processing, i am all in favor for that :) Well, it is not really possible, which is why this is a problem. It's completely acceptable for volunteers to spend their time how they see fit, prioritising the work they think's most important, or prioritising other parts of their life over Debian if they think that's important. Sure. But by doing so, they stale the work of others, especially as things are important for the release schedule. That's not to that I don't think it's worth improving this and finding ways to encourage people to commit more time to Debian or to use that time more effectively; and for this particular case I've already described what activity I think would lead to the biggest improvement. but it is perfectly normal for the ftp-masters to do it ? Meanwhile, I think claims like You wouldn't accept this from normal people, but it's standard procedure for ftpmaster are likely to simply exacerbate the problem. How well, i am grilled with the ftp-masters anyway, so ... YMMV, of course, and if it does, you might well be right while I'm wrong. Whatever experience I have might provide a better basis for my judgements to rest upon than yours have; or it might mean I'm too close to the problem and completely off-track. And it is worse since the email don't come from random users, but from the exact same DDs who are all working together to make it all happen. Ideally all requests from everybody would be acted upon quickly and effectively; but that's not feasible, so they get prioritised. Taking developers more seriously than users, or release managers more seriously than developers are just two variants of the same prioritisation scheme, so I don't think it's worse at all. yeah, but for packages, we have the QA team, which can take over, or some random developer looking at the MIA status of a developer or a package can take over. For the ftp-masters this is not only not possible, but any critic is often rejected and there is a certain amount of taboo going on, which then explodes in huge flames, and the ftp-master feel aggressed by it, and don't react and then you go in circle again. And again to my purely technical question. Is it really necessary for kernel-source-2.6.11 to go through NEW once it is uploaded for example ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Anthony Towns aj@azure.humbug.org.au wrote: As a concrete example, I don't think http://ftp-master.debian.org/new.html resolves the complaints about NEW and hence I don't think that the NEW issue is an example of a communication problem at all. http://ftp-master.debian.org/new.html failing to resolve the complaints about NEW doesn't demonstrate that it's not a communication problem. Complaints about NEW can roughly be split into three catagories: 1) It takes too long This isn't a communication problem. It would be nice if it went faster, but it's up to the ftp-masters to decide whether that's possible or not. 2) It isn't happening This is (at least partly) a communication problem. When NEW processing appeared to stall recently, most of the complaints I heard weren't that it had stopped, but that nobody knew /why/ it had stopped. 3) My package has been sitting in the queue for ages and other packages have been processed This is a communication problem. I'm aware that packages will tend to get left for later if they're awkward, but this sometimes ends up with packages sitting in the queue for months. Passing on some information as to /why/ it's being delayed would make it easier for the maintainer to either clarify the issues or upload a new package that doesn't have them. Of course, this would take time and resources, so it's not clear how practical it is to do. So I think saying The NEW issue has nothing to do with communication is difficult unless you clarify what The NEW issue is. Communication isn't about providing information - it's about providing the information that people need. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ftpmasters' job and the DPL (was: Question for candidate Towns)
Anthony Towns aj@azure.humbug.org.au wrote: Kalle Kivimaa wrote: anyway: what do you think the NEW issue is an example of? Not having enough time in the day. The resolutions to that are: (a) reprioritising things (b) making more time available (c) making things take less time (d) training other people I don't think (a)'s plausible in the case of NEW; there don't seem any obviously unimportant things that're being mistaken as being important and sucking up too much time. (b) is generally tricky, and is mostly a motivational issue, and thus generally not a short term one. (c) and (d) are both ideal, but also involve taking time out now for a gain in future (ie, scripting or rethinking things to work out how they can be done better, or finding and mentoring newbies to help with the tasks) -- and when the problem is a lack of time right now, they're hard to implement. That sounds plausible. Most of ftpmaster are at the release cabal meeting Steve announced on -project yesterday; I expect the current ftpmaster issues'll be resolved before we're done on Monday anyway. I would have liked for them to have been resolved already, but I find it very hard to push for things like that when messages like Martin's to -project [0] are more or less left to stand. I don't like the tone used in that thread, and I don't want to repeat it here. But some of the concerns raised seem valid to me. Let me give one example, an unimportant one in hope not to start a flamewar, and because I happen to be involved. At the end, I'm going to ask some questions to you as a DPL candidate; the others can of course also answer if they want to. - Early in January this year, I uploaded a version of tetex-bin that produced a binary package for the kpathsea library with a new soname, and a new package name. Shortly after this, there was a discussion on -devel about exactly such things (in which you, Anthony Towns, were involved), and as a followup I wrote a mail to ftpmaster, saying you should reject that package because I did the naming wrong. - After some more thinking and reading of the thread, I changed my mind. I wrote again to ftpmaster, saying this, and that my case was probably one of the special ones were the naming I chose was acceptable. - However, I never received an answer to that second mail. Since it wasn't important for the release or any bugfix to get that package in soon, I didn't complain; but in fact I was kind of puzzled to not get any answer. I was unsure whether I should proceed uploading packages with the naming I thought correct, or finally make the change to the other scheme you said (on -devel) was usually correct. I also didn't know whether the reason why the package was not processed had anything to do with the fact that this issue might be controversial (rumor goes that easy packages are processed first). If the issue would have been time-critical, I would not have known whether asking again was a good idea, or would actually annoy the ftpmasters, and slow down processing. As a DPL candidate, do you feel that such a feeling of uncertainty, and of being at the mercy of somebody you can't talk to, occurs frequently among developers, and if yes, do you think it is a problem for their motivation to do Debian work? Do you think that the uncertainty about the criteria for accepting or rejecting a new package can make developers to hang on to badly designed old solutions, instead of proposing and implementing/packaging something really new? If the answer to any of these is yes, do you think the DPL can do anything about it? What? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Fri, Mar 04, 2005 at 11:28:16AM -0800, Anthony Towns wrote: Sven Luther wrote: And again to my purely technical question. Is it really necessary for kernel-source-2.6.11 to go through NEW once it is uploaded for example ? It's not a technical issue it's a legal one -- our approach to No, i don't think so. We only have not coped yet with the fact that we have a set of names (kernel-source-2.6.11, kernel-source-2.6.10, kernel-source-2.6.9, ... and so on), which concern one and the same package. Compare this to a kernel-source package, which would have version 2.6.9, 2.6.10, ... There really is no technical difference between a package with the version embeded in the name where various version can be simultaneously in the archive, and a package that has one name or various simultaneous versions. That is was wildcard and regexps are for. satisfying the legal requirements for including crypto software in main Arg, the main reason for this is the big-brother reporting of all our work to the US authorities :( require us to manually process each package with a new name. Yes, it really is necessary. Sure, move our archive out of the US, and be gone with the problem. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Matthew Garrett wrote: Erm, ftpmaster hat, I guess. Anthony Towns aj@azure.humbug.org.au wrote: As a concrete example, I don't think http://ftp-master.debian.org/new.html resolves the complaints about NEW and hence I don't think that the NEW issue is an example of a communication problem at all. http://ftp-master.debian.org/new.html failing to resolve the complaints about NEW doesn't demonstrate that it's not a communication problem. Complaints about NEW can roughly be split into three catagories: 1) It takes too long 2) It isn't happening These are the same issue: it's a queue, packages uploaded now will be processed when NEW starts getting processed regularly again. This is (at least partly) a communication problem. When NEW processing appeared to stall recently, most of the complaints I heard weren't that it had stopped, but that nobody knew /why/ it had stopped. I think the communication issues are just a stand in for complaints of the underlying cause. If they weren't, I think the new.html page should be more of a solution -- to the point where people would be bringing it up and saying Hey, there's this new page that gives you some idea of where you are in the queue! How cool!!!. There are two other bits of information people could ask for: Why aren't individual ftpmasters spending time on Debian?, which I don't really think is anyone's business, and far more reasonably Well, when will they be processed?. But the latter doesn't even have a known answer; and somehow I expect the response to We don't know. would be Well, you should! This is utterly unacceptable not Thankyou for communicating with us. The communication isn't perfect, but I don't think making it perfect would actually be a significant improvement. 3) My package has been sitting in the queue for ages and other packages have been processed This is a communication problem. No, this is a policy problem. Communication is easy: hit M for manual reject, write a note, and it's all done. Or hit P for prod to write a note to the maintainer with the possibility of accepting the package anyway, or leaving it in the queue for later reconsideration. The issue for packages like mplayer and hot-babe is that it's not clear that they can be accepted, but it's also not clear that they should be rejected. And until one or the other becomes clear, they're left in the queue. I actually think that's a good result: far better to keep track of the problematic packages, than to just REJECT them with a reason like doesn't seem like a good idea and have them randomly reuploaded later. It also seems like a better idea to let packages that don't seem like a good idea sit in the queue, rather than get uploaded and distributed around the world. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
On Fri, Mar 04, 2005 at 11:07:06AM -0800, Anthony Towns wrote: Kalle Kivimaa wrote: Anthony Towns aj@azure.humbug.org.au writes: resolves the complaints about NEW and hence I don't think that the NEW issue is an example of a communication problem at all. This is getting slightly too detailed discussion for a DPL, but anyway: what do you think the NEW issue is an example of? Not having enough time in the day. The resolutions to that are: (a) reprioritising things (b) making more time available (c) making things take less time (d) training other people What about (e) automating tasks which don't really need human intervention ? What amount of work goes into handling the new-version-embedded-in-package-name NEW work ? And what is the average waiting time of those packages ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Sven Luther wrote: I have some real trouble with the fact that all the work i do for debian is reported to the US secret services or whatever by the ftp-masters and our archive handling services, and i certainly did *NOT* agree to this being the case. Everyone subscribed to debian-devel-changes gets notified of every change you make; and we certainly welcome everyone to subscribe to that, including the US export bureau or secret service. That we happen to provide a slightly briefer summary for the BXA doesn't really change that in any way. In fact, the summary excludes the names of package maintainers as well as other information that gets posted to -devel-changes. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Sven Luther [EMAIL PROTECTED] writes: I have some real trouble with the fact that all the work i do for debian is reported to the US secret services or whatever by the ftp-masters and our archive handling services, and i certainly did *NOT* agree to this being the case. What are you talking about? Debian prohibits anonymous developers, always has; for the longest time this was the only real restriction on joining Debian: you had to find a few other Debian developers to verify you had a real ID. It's not like this is some private information. Work for Debian is public. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns
On Fri, Mar 04, 2005 at 09:09:50PM +0100, Sven Luther wrote: On Fri, Mar 04, 2005 at 11:07:06AM -0800, Anthony Towns wrote: Kalle Kivimaa wrote: Anthony Towns aj@azure.humbug.org.au writes: resolves the complaints about NEW and hence I don't think that the NEW issue is an example of a communication problem at all. This is getting slightly too detailed discussion for a DPL, but anyway: what do you think the NEW issue is an example of? Not having enough time in the day. The resolutions to that are: (a) reprioritising things (b) making more time available (c) making things take less time (d) training other people What about (e) automating tasks which don't really need human intervention ? That would be a case of (c), to my mind. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Steve Langasek wrote: As someone who is both an ftpmaster and a DPL candidate, could you also tell us what resources you (or the ftpmasters as a group, if you believe it's appropriate to speak for them) would appreciate? The most valuable thing I can think of would be to not have to have some flame or another continually burning on the lists about how ftpmaster isn't doing a satisfactory job in one way or another. The most negative consequence of that is that doing anything good tends to match something someone's recently demanded of ftpmaster, which leads people to think that it's not a good idea to implement and announce things as soon as possible, lest it be misinterpreted as being a result of the flaming. The continual politicisation and targetting of ftpmaster and similar groups in DPL elections as well as at other times also makes technical work more difficult in my opinion. That's /my/ impression at any rate. I don't claim to speak for anyone else on ftpmaster or in any other role in the project. If elected DPL I'd aim to remove the list problems by having delegates lead discussion of problems in their fields of expertise and having the usual flamewars be declared off topic and either having the thread killed or, if necessary, the poster suspended. I think it's easy to avoid those sorts of flamewars by starting a thread with a patch instead of complaints, and I think pretty much all our delegates are dedicated enough to be willing to raise problems themselves if they can be confident it won't just result in a pointless debate. So I don't think that any important discussions will be made impossible by this. I'd aim to remove the politics by offering fairly unconditional support for people filling other roles in the project -- where decisions have been delegated, it's not appropriate to continually second guess and micromanage. I think all of the delegates in Debian are doing a satisfactory job at the moment, although there are some additional roles that could be created and filled, and, of course, all of them could do a better job. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Thu, Mar 03, 2005 at 09:27:36AM -0800, Anthony Towns wrote: Steve Langasek wrote: As someone who is both an ftpmaster and a DPL candidate, could you also tell us what resources you (or the ftpmasters as a group, if you believe it's appropriate to speak for them) would appreciate? The most valuable thing I can think of would be to not have to have some flame or another continually burning on the lists about how ftpmaster Well, you seem to mention mostly the flames, but forget about the fact that most reasonable mails to the ftp-master email address also get fully unreplied too, even when like it happened to me recently, the request involved something relatively time-critical with the debain-installer rc3 schedule. I understand that flames are entirely out of order, and me asking for the question to be debated was not aimed at creating a new flamewar on the subject, but because i really believe we have a problem in this field, and one which can at times create undue delay at critical moments of our release process or the release process of individual small-teams. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Hi Anthony, On Wed, Mar 02, 2005 at 07:41:09PM -0800, Anthony Towns wrote: I would like to know from the DPL candidates what is their opinion on way the ftp-masters handle the NEW queue, I think this is the wrong question. The right question to ask is what the ftpmasters think of the way NEW is being handled, and what resources they would appreciate. As the following question is directed to you alone, I would appreciate an on-list answer rather than waiting for the IRC debate. (Any questions I may have for the debate will be sent privately to the moderators.) I believe that your previous mail satisfactorily answered the question about what you think of the way NEW is being handled. As someone who is both an ftpmaster and a DPL candidate, could you also tell us what resources you (or the ftpmasters as a group, if you believe it's appropriate to speak for them) would appreciate? If you feel this is off-topic for -vote, by all means please redirect the discussion to a more appropriate list. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
