Re: Question for candidate Walther
On Fri, Mar 11, 2005 at 04:05:03PM +1100, Daniel Stone wrote: Hi Jonathan, Hi Daniel. Good to hear from you. It's been a while. In your platform[0], you state: I have a proven history of releasing software on time, on schedule. Project Xouvert, a stripped down version of the X11 source code, was released two times, six months apart. We didn't achieve many of our more ambitious goals, but we got a working release out the door on time, both times. This did not in any way line up with my recollection of how Xouvert fared at all, so I challenged you about it on IRC: Sorry I didn't get back to you sooner. I don't usually IRC from work, and just got home. Your perceptions are definitely of concern, so I'll address them here. Contrast this with the Xouvert 0.1 announcement[2]: Date: Sun, 7 Dec 2003 05:24:40 -0800 This release was either two months and six days, or one month and six days, late; depends on how you look at it. I didn't go digging through the archives before writing my platform. You may be right. Most of our announcements were done via our webpages. Since we lost our entire edit history for those when the repositories got wiped, I can't go through and show exactly how the December 7 release announcement matches up with on time, but the whole team felt pretty proud of our schedule keeping. I believe that by November 1 what we offered was the XFree86 sources just before the point where they changed the license, made available to the public through the arch revision control system. Since we hadn't made any changes, we didn't stamp it with a release number until we'd made some changes. Internally we called it the developers release. So, yes, we had shipping source code on time, but you are right, it wasn't a release as the outside world would consider it, involving modifications to the code, etc. Thanks for the trip down memory lane. I'm sorry if you feel misled; that wasn't my intent. March's list traffic[10] sees your first post in months, in which you announce[11] that there has been a long radio silence, and that 'Xouvert at the moment is the XFree86 4.3 X server with Alan Cox's VIA drivers added'. There was no code behind this. Indeed, as you state later in the announcement: I believe your statement on what Xouvert was at the time referred to plans, not code. You mention that you were probably moving to the commit repositories to fd.o; I do not recall this ever having happened, there is no 'xouvert' group on gabe.freedesktop.org[12], and no posts from you to [EMAIL PROTECTED] (the fd.o admin list). Our activities on freedesktop.org all happened before gabe came up. I think we had an account on pdx. We used it as a mirror until the hard drive crash, but never uploaded the second release to it. Noone on the Xouvert team was ever made aware of the sitewranglers mailing list. Even the existence of lists.freedesktop.org is a fairly new thing. The second release was real; we took the X.org sources, applied some patches, and ran it through a custom perl script that stripped the server code out from the rest of the CVS goop called X11. The release was downloadable from the Xouvert.org site. While I was busy stamping out fires elsewhere, just before the second release, the webmaster had to deal with some issues on the server, and made some changes to the website, including moving things around. At that point, lacking repository histories, I threw in the towel; X.org was picking up steam, and although there was still a significant niche for Xouvert, everyone on the team, including myself, was moving on to other life obligations. One of the (many) headaches that persuaded me not to revive Xouvert after the second release was the design of the arch revision control system; setting it up securely was not trivial at that point in its development. That may have changed; I respect the abilities of Tom Lord a lot. If I were to revive Xouvert today, I would use darcs. It is vastly easier to use and administer than arch. Darcs is what Xouvert needed from the beginning. There were three follow-up questions (none with any real effect on the project, just musings about X, mainly; although an answer for 'what are you going to do now they've changed the licence?' Xouvert dealt with the license change issue at its inception. Simply put, we grabbed the source code from just before the license change. Was there another license change since then? Someone suggested rewriting the build system again. I did. I planned to use the scsh scheme interpreter as a build system to replace imake, cpp, m4 and make in one felling swoop. Something it would still be nice to do. I don't believe in XML. It is a weak and sickly bastardization of SGML. www.xouvert.org now states that the release slated for April 1, 2004 (sic; should be April 5), was 'the last release of Xouvert for now'[16] and that all the developers had moved on. However, there was never any announcement of: * a release, *
Re: Question for candidate Walther
On Fri, Mar 11, 2005 at 12:02:10AM -0800, Jonathan Walther wrote: On Fri, Mar 11, 2005 at 04:05:03PM +1100, Daniel Stone wrote: Contrast this with the Xouvert 0.1 announcement[2]: Date: Sun, 7 Dec 2003 05:24:40 -0800 This release was either two months and six days, or one month and six days, late; depends on how you look at it. I didn't go digging through the archives before writing my platform. You may be right. Most of our announcements were done via our webpages. Since we lost our entire edit history for those when the repositories got wiped, I can't go through and show exactly how the December 7 release announcement matches up with on time, but the whole team felt pretty proud of our schedule keeping. I believe that by November 1 what we offered was the XFree86 sources just before the point where they changed the license, made available to the public through the arch revision control system. Since we hadn't made any changes, we didn't stamp it with a release number until we'd made some changes. Internally we called it the developers release. So, yes, we had shipping source code on time, but you are right, it wasn't a release as the outside world would consider it, involving modifications to the code, etc. Thanks for the trip down memory lane. I'm sorry if you feel misled; that wasn't my intent. Er, from the IRC log[0] of 20041207: SirDibos btw, I'm havnig a shower now, then updating the website. should take an hour or so. then we release to the public! and later on in the same day: DanielS can i just ask, though, to satisfy the cynic in me - what's changed since it was a few hours away, a month and a half ago? :) SirDibos DanielS: what changed is, me, Andri, and a couple others have actually checked the source out of the arch archive and compiled it, whereas 2 months ago there was no source ^_^ As for the Arch archive, yes, you announced previously that there would be an arch import on the date the first release was scheduled for. However: -r--r--r-- 1 1073 users 20747144 Dec 7 2003 xouvert--mainline--0.1--base-0.src.tar.gz This seems to line up with the theory that the release occurred on the 7th of December 2003, which is so far the most plausible theory. Which would put it one or two months, plus six days, late. It seems odd that you saw fit to pre-announce that there would be a 'hackers release' later on the 1st of November[1], yet didn't bother to actually follow that up with a real release. This seems like absolutely bizzare behaviour to me: why would you bother to 'pre-announce' that something would happen later that day, and then never bother following that up with a full announcement? Especially when you actually do that full announcement, and publish the sources, a month and six days later. I do have a very good recollection of you guys battling arch imports for a very long time, which was anecdotally backed up on IRC to me today. March's list traffic[10] sees your first post in months, in which you announce[11] that there has been a long radio silence, and that 'Xouvert at the moment is the XFree86 4.3 X server with Alan Cox's VIA drivers added'. There was no code behind this. Indeed, as you state later in the announcement: I believe your statement on what Xouvert was at the time referred to plans, not code. You mention that you were probably moving to the commit repositories to fd.o; I do not recall this ever having happened, there is no 'xouvert' group on gabe.freedesktop.org[12], and no posts from you to [EMAIL PROTECTED] (the fd.o admin list). Our activities on freedesktop.org all happened before gabe came up. I think we had an account on pdx. We used it as a mirror until the hard drive crash, but never uploaded the second release to it. Noone on the Xouvert team was ever made aware of the sitewranglers mailing list. Even the existence of lists.freedesktop.org is a fairly new thing. gabe is the same machine as pdx, and /home was preserved as /home/compromised when we renamed it gabe after the reinstall (indeed, it is still available today). I did later find the first release (as an arch branch with only a base-0 -- only one commit, ever), in /home/compromised/www/twiki/Software/xouvert; this was the old http://freedesktop.org/Software/xouvert/. As for lists.fd.o, it's just part of our effort to move everything to service-based names; sitewranglers has existed since very, very early on as [EMAIL PROTECTED] and [EMAIL PROTECTED] The second release was real; we took the X.org sources, applied some patches, and ran it through a custom perl script that stripped the server code out from the rest of the CVS goop called X11. The release was downloadable from the Xouvert.org site. Was it? web.archive.org does not show any reference to this ever, it is not downloadable anywhere today, and it was not announced anywhere (not on the mailing lists, not on
Re: My platform
At Thu, 10 Mar 2005 03:43:48 +0100, martin f krafft wrote: My sincere apologies for the delay. Note up front: I have not yet looked at your platform. [...] Could you please state in public that you did not use the delay in any way to gain an advantage by looking over the others' platforms and the ensuing discussion? I did not use the delay in any way to gain an advantage by looking over the others' platforms and the ensuing discussion. (I was too busy writing the platform!) I understand your concerns, but now that you've had time to read my platform, I hope they no longer remain. At Thu, 10 Mar 2005 04:25:01 +0100, martin f krafft wrote: I have a few ideas about how to improve communication within Debian and I will try to bring an attitude of tolerance and more efficient communication to the mailing lists. Could you please be more specific and give us more details about these ideas? Sure. (I hope you don't plan to choose your next DPL based on their undeveloped personal ideas for mailing list policies, however) Like most other Debian Developers, I think we have an unhelpful culture of flaming, ad hominem attacks and general posturing on our lists. Improving this culture is going to be difficult, and our noisiest contributors are the ones that are going to be most affected. Given Debian's size and geographical distribution, I think holding more in-person meetings is not going to make much difference to the lists. It would cost US$millions to bring every developer to the one place, so clearly only regional gatherings are possible. We already have various debconfs that bring American and European developers together (and those of us in less densely populated parts of the planet do the best we can), and yet clearly the tone of the mailing lists has not improved. As a general strategy, I'd like to move a lot of the actual discussion off the mailing lists and into some higher bandwidth, higher turnover medium. For small focussed teams, in-person meetings such as the recent one between release and ftp-master teams are the ideal and should of course be continued. As I mention in my brief debian-thoughts article (linked from my platform), something I'd like to explore is VoIP - now that the tools and the bandwidth seem to be available. Even IRC, with its famed ability to waste time, seems to somehow avoid the nastiness of public mailing lists. The approach I think is going to have the most dramatic impact here is of course mailing list moderation. Although some people are hotly opposed to this form of censorship, this is something I believe the project would benefit from and something we need to experiment with. I know the listmasters have some ideas here and there is obviously huge variation in possible algorithms - I would think different lists might even want different policies. I think this is a discussion we need to have and I think its an area where we need to feel confident to try out different ideas, make mistakes and not be afraid to roll them back. -- - Gus pgpsOqv9XzZg6.pgp Description: PGP signature
Re: Question for candidate Walther
We will extract the X server source from the XFree86 CVS repository, and make it compile stand-alone. Then we will package it together with the latest video drivers and bugfixes to coexist with current distributions of XFree86. We hope to incorporate the DRI and Utah-glx work by release time, but if will definately have it incorporated shortly after release. Who was responsible for the Berlin Consortium? I vote for that guy. Manoj, did you tally that? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-women obscurity, was: Clarification about krooger's platform
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: The idea to ignore trolls is hardly new, or unusual. Nor is it a policy, in the sense that anyone is ordered to ignore them under pain of expulsion. [...] Not in that sense, but that sense doesn't follow directly from the word policy. I'd expect someone consistently ignoring it to be corrected, but ICBW. If you think this is *wrong*, then why? Because you have a right to be responded to no matter what you say, even when you are hostile to the purposes the list was created for? I'm not hostile to balancing debian's composition. I'm hostile to discrimination, but I was told that wasn't a list purpose: are you saying it is? Why do you know better than others? I think I've stated why enough for now. Texts about political theory or conflict resolution might help you to understand it. The smallest (maybe cheapest) I've here is Nigel Risner It's a Zoo Around Here but I don't know where that's available now. -- 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
Final announcement of 2005 DPL election debate
Finally, after many complications and several hundreds of bytes of data exchanged between the involved (wow!), it is my pleasure to announce the *** 2005 DEBIAN PROJECT LEADER ELECTION IRC DEBATE *** The 2005 DPL IRC Debate will be held on Wednesday 16th March at 06:00 UTC. We apologise to all who are inconvenienced by this time, but it was the only way to get all six candidates together. We will use 4 IRC channels for the debate. All channels will be logged, and logs are going to be made available after the debate. All channels are on the Freenode IRC network: irc.debian.org. The four channels and their purposes are: #debian-dpl-debate - On this channel the candidates will answer questions and debate. The channel is open to the public in read-only mode. Only the debate chairs (Helen Faulkner and Martin Krafft), and the DPL candidates will be voiced. #debian-dpl-discuss - This channel will be open for general discussion of matters relating to the debate. As well as discussion of the debate, anyone may post a question for the candidates to this channel. We will choose some of the questions posted to ask the candidates during the course of the debate. A number of volunteers will monitor the channel to make sure that it stays productive. Anyone behaving in a sufficiently disruptive way will be devoiced or removed from the channel (not that we expect this to happen). #debian-dpl-replies - This channel will be used to collect the replies of the candidates to the questions asked in the first part of the debate. The channel will be used for nothing else. Its purpose is to allow us to make sure that all candidates have an equal amount of time to answer each question, and to allow us to paste their replies to #debian-dpl-debate in a coherent way. The channel will only be open to the debate chairs (Helen Faulkner and Martin Krafft), and the candidates. #debian-dpl-moderation - This channel is closed to the public and used by the moderators of the #debian-dpl-discuss channel to communicate with the debate chairs. DEBATE FORMAT The debate will run for 2 hours, using the following format: * The first 60 minutes will consist of a series of questions, each of which is directed at all of the candidates. For each question, the following steps will be taken: 1. On #debian-dpl-debate Helen or Martin asks the question and sets the time limit for replies (time limits will vary between 1 and 6 minutes). 2. At the time limit, Helen or Martin will call Time!. The candidates must then paste their replies into #debian-dpl-replies. Any candidate who does not paste their reply within a reasonable time frame will lose the chance to reply to that question. 3. Helen and Martin will collate the replies, and paste them into #debian-dpl-debate for the audience to read. Candidates may ask for clarification of another candidate's response, although if possible, such questions should be kept until the second half of the debate. * There will be a 10 minute break after the first half. * The last 50 minutes of the debate will consist of a moderated (not censored) discussion between the chairs and the candidates, on #debian-dpl-debate. Helen and Martin will pose questions or topics for general discussion between the candidates. The chairs will moderate the discussion to ensure that all the candidates have roughly equal opportunity to express their viewpoints. The questions asked in both stages of the debate will be a mixture of questions prepared beforehand by Helen and Martin (taking into account the many proposed questions we have received), and questions that are raised by people in #debian-dpl-discuss during the course of the debate. In both stages of the debate, the candidates should follow the instructions given by the chairs. All such instructions will be aimed at keeping the debate running smoothly and keeping it fair to all candidates. Failure to follow an instruction from a chairperson will result in the offender being warned. Re-offenders will risk being devoiced for a period of time. Of course this is not at all expected to happen :) The candidates may participate in discussions on #debian-dpl-discuss as they see fit. Let the games begin! -- .''`. 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 Walther
Scripsit Daniel Stone [EMAIL PROTECTED] No, I'm afraid I still do not believe that the first release occurred on time, or that the second release ever occurred, and my faith in your release abilities is very low for someone who listed it as its absolute top priority. I totally think we should elect this guy, if only to hear his end-of-year report in the beginning of 2006! | Yeah, we released Sarge all right, but somebody accidentally | microwaved the dvd, so there was not much point in announcing the | release afterwards, was there? Then a truly committed team of | hard-working Debian volunteers recreated the lost release from the | baseline Woody source, and Etch was well on its way to a scheduled | October 2005 release when that rather unfortunate asteroid incident | at the colo happened on November 19th, but I'm sure the aliens | really enjoyed Etch. Eventually we reconstructed our distribution | based on a set of Potato floppies donated by Germaine Greer, and as | of today Claw (which will consist of Slink extended with a prettier | stylesheet for Apache's default front page) is in deep freeze and | expected to release later this afternoon. -- Henning MakholmThere is a danger that curious users may occasionally unplug their fiber connector and look directly into it to watch the bits go by at 100 Mbps. -- 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 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
Question to all candidates
The current Technical Committee is inactive; in the past two years they have only made two rulings: * 2004-06-24 Bug #254598: amd64 is a fine name for that architecture. * 2004-06-05 Bug #164591, Bug #164889: md5sum /dev/null should produce the bare md5sum value. The md5sum ruling was a bug submitted, referred and decided by the Technical Committee chairman. In effect, he used his power in such a manner to expect that any bug he files will lead to a tech-ctte decision. Do you believe that the tech-ctte should be relatively inactive? Or do you believe that an inactive Technical Committee is a bad thing? If the latter, do you propose (as they would be your delegates) to make any changes to the current make-up of the committee. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Question: Do you have the time to be DPL?
Given the DPL's role involves a fair amount of travel, speaking, giving interviews to the press, etc, do you think that you will have sufficient time to do a good job as DPL given your other commitments to Debian? How do you see your other responsibilities within Debian suffering as a result of you being elected DPL? Why is Debian better served by having you as DPL rather than in your current role? -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for A. Towns - NM
On Thursday 10 March 2005 6:53 pm, Anthony Towns wrote: Personally, I don't see any reason why having filtering on the client is better than having it on the server -- even if just to stop people from getting confused at the debian-devel they read being different to the debian-devel others see. For those who read our mailing lists via the web archives, client side filtering isn't really possible, in any case. Because filtering on the client is configurable by the client and not by some mysterious person who has their own private biases. You have a good point on the web archives. If we had a collaborative mail-filtering system (like Razor) then we could use the concensus arrived at by the system's users. That would be a more suitable solution than, say, using your own private Spam Assassin ruleset. No, the central motivation for the project is to make a good, free operating system. The Deb stands for Debra, not Debating. So, is that free as in beer? If freedom of expression isn't a priority then what exactly is Software Libre? I do agree with you that endless debate for the sake of lip-flapping is one of the project's biggest challenges. I just think you are over-simplifying the solutions. -- Ean Schuessler, CTO [EMAIL PROTECTED] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 Walther
Graydon Hoare. I hear that he has apologized for that whole thing. On Friday 11 March 2005 3:54 am, Brian Kimball wrote: We will extract the X server source from the XFree86 CVS repository, and make it compile stand-alone. Then we will package it together with the latest video drivers and bugfixes to coexist with current distributions of XFree86. We hope to incorporate the DRI and Utah-glx work by release time, but if will definately have it incorporated shortly after release. Who was responsible for the Berlin Consortium? I vote for that guy. Manoj, did you tally that? Thanks. -- Ean Schuessler, CTO [EMAIL PROTECTED] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com -- 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 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 to all candidates
Scott James Remnant wrote: The current Technical Committee is inactive; in the past two years they have only made two rulings: * 2004-06-24 Bug #254598: amd64 is a fine name for that architecture. * 2004-06-05 Bug #164591, Bug #164889: md5sum /dev/null should produce the bare md5sum value. Do you believe that the tech-ctte should be relatively inactive? Or do you believe that an inactive Technical Committee is a bad thing? If the latter, do you propose (as they would be your delegates) to make any changes to the current make-up of the committee. Oh, on rereading I guess I should note explicitly that the tech ctte aren't the DPL's delegates in any way, shape or form. Anyway. In one sense an inactive technical ctte should not be an issue: our constitution allows inactivity on anyone's behalf, and so we should be able to cope with that. And, indeed, mostly we do. I think it's actually bad in two ways though: one is that it sets a bad example for other groups within Debian, the other is that as one of the recommended ways of resolving technical disputes it makes it harder to make decisions. I don't think the membership of the ctte is the major problem, instead I think it's more an issue of the tradition that's built up of how and when the tech ctte should act. Traditions like that aren't easy to change, though (that's why we call them traditions), and since the technical ctte is designed as one of the counterbalances to a dictatorial/tryannical DPL that's not something the DPL can resolve on his/her own prerogative. I think the easiest way of breaking up what I see as the bad traditions the tech ctte have established over the years is with some fairly serious shock treatment. I think the following shocks would work: * changing the membership completely, ie having everyone on the tech ctte step down, and not immediately step back up, even if they're (otherwise) the most suitable candidate for the role. * changing the informal eligibility requirements, from being experienced and respected to being active and involved, by solely or mostly appointing active delegates to the positions * having the position of chair rotate amongst ctte members every two to three months * having the normal process for handling of issues before the tech ctte be the ctte chair explaining his/her opinion immediately, and that being authoritative unless someone else on the ctte demurs within about a week * potentially establishing a tradition of between one and three people stepping down from the tech ctte and being replaced each year I'm not sure if all of those are possible and some might not be desirable; but hopefully there are enough there that if some of the shocks don't happen, the remainder are enough to resolve the tech ctte related problems in the project. I think good roles to have represented on the tech ctte include ftpmaster, buildd maint/ports support, security support, QA, release manager, policy maint, webmaster, listmaster, BTS admin, dpkg/apt development, debian-installer development, toolchain (glibc, gcc, etc) suppport, and similar roles that the project as a whole depends on. The benefit of this is that people involved in those roles generally have a good idea of what's going on across the project (since whenever they break anything, people crawl out of all sorts of obscure nooks and crannies to complain :), and the project already relies on them, so presumably trusts them to not screw it around too much. (Given the restrictions on how many people can be in the tech ctte at any one time, it's fortunate there're a few people that individually are involved in many of those roles. :) Anyway, like I said, this isn't something the DPL can even come close to doing unilaterally; so my approach, if elected, will be to talk to various people in those roles to see if they'd be willing to work on a reconstituted tech ctte, and to see what concerns the existing tech ctte have about the prospective new team and ensure they're addressed, so that we can aim for an amicable handover that at least satisfies the people directly involved if not everyone working on Debian. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question: Do you have the time to be DPL?
Matthew Wilcox wrote: Given the DPL's role involves a fair amount of travel, speaking, giving interviews to the press, etc, do you think that you will have sufficient time to do a good job as DPL given your other commitments to Debian? I expect so -- in the worst case, all of my other commitments to Debian can be and have been covered by others as necessary, whether by other members of the team (such as ftpmaster and debbugs) or by assistants/co-maintainers (such as debootstrap and, in the past, my RM work), or by random other people (whether NMUs or workarounds like http://bjorn.haxx.se/debian/). How do you see your other responsibilities within Debian suffering as a result of you being elected DPL? I don't think this is a zero-sum game, and I hope that as DPL I'd be able to make it easier for other people to contribute too. One of the more important tasks of leadership, in my opinion, is making sure the people you're trying to lead grow and improve in their skills and areas of responsibility too. Why is Debian better served by having you as DPL rather than in your current role? I don't think that's really for me to say -- I've indicated what I plan to work on, it's really for everyone else to judge whether that's a good thing or not. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: My platform
martin f krafft wrote: Anyway, how are you going to ensure that we don't scream at each other over VoIP lines? Traffic control? :) High frequency filtering? :) Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for A. Towns - NM
Ean Schuessler wrote: No, the central motivation for the project is to make a good, free operating system. The Deb stands for Debra, not Debating. So, is that free as in beer? If freedom of expression isn't a priority then what exactly is Software Libre? Free software's about writing good code, and making it freely usable and modifiable by anyone. Freedom of expression is about being able to say whatever you think, no matter how counter-productive, irrelevant, wrong, meaningless, offensive, or uninteresting it is. That's a good thing to have *somewhere*, but better to keep it on your blog than on Debian's mailing lists. That, at least, is why I have a blog; and it's why I even wrote a plugin so that some of my more offensive/uninteresting/irrelevant posts don't even make it to Planet Debian. The best way Debian can promote freedom of expression is by providing software to enable it (such as blogging packages, and a good OS to run on a server that hosts lists, debates, or blogs) -- not by trying to reuse its fora as an outlet for random opinions. I do agree with you that endless debate for the sake of lip-flapping is one of the project's biggest challenges. I just think you are over-simplifying the solutions. In my experience, if you don't keep the principles simple and direct, the policies become byzantine and unimplementable. I also don't think it's a good idea for a DPL to go too much into defining policies that someone else will have to implement anyway. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-women obscurity, was: Clarification about krooger's platform
MJ Ray [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] wrote: The idea to ignore trolls is hardly new, or unusual. Nor is it a policy, in the sense that anyone is ordered to ignore them under pain of expulsion. [...] Not in that sense, but that sense doesn't follow directly from the word policy. I'd expect someone consistently ignoring it to be corrected, but ICBW. It's not policy regardless. It's a recommendation about what will make the list more useful and pleasant. If you think this is *wrong*, then why? Because you have a right to be responded to no matter what you say, even when you are hostile to the purposes the list was created for? I'm not hostile to balancing debian's composition. I'm hostile to discrimination, but I was told that wasn't a list purpose: are you saying it is? Why do you know better than others? The list discriminates on the basis of *topic*, but not on the basis of the gender of the *contributor*. Get it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Question to all candidates.
Hello DPL candidate, My question is: How do you see the relation between Debian and Ubuntu in the future? Thanks in advance for your answers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- 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: My platform
On Sat, Mar 12, 2005 at 04:44:19AM +1000, Anthony Towns wrote: martin f krafft wrote: Anyway, how are you going to ensure that we don't scream at each other over VoIP lines? Traffic control? :) High frequency filtering? :) No, come on, this would be discriminatory for women, youth and soprano singers ;-) -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-women obscurity, was: Clarification about krooger's platform
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: MJ Ray [EMAIL PROTECTED] writes: [...] Not in that sense, but that sense doesn't follow directly from the word policy. I'd expect someone consistently ignoring it to be corrected, but ICBW. It's not policy regardless. It's a recommendation about what will make the list more useful and pleasant. I refer you to a dictionary, sorry. If you think this is *wrong*, then why? Because you have a right to be responded to no matter what you say, even when you are hostile to the purposes the list was created for? I'm not hostile to balancing debian's composition. I'm hostile to discrimination, but I was told that wasn't a list purpose: are you saying it is? Why do you know better than others? I notice that you do not directly answer any question. The list discriminates on the basis of *topic*, but not on the basis of the gender of the *contributor*. Get it? Why do you think that is the case? -- 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: debian-women obscurity, was: Clarification about krooger's platform
MJ Ray [EMAIL PROTECTED] writes: If you think this is *wrong*, then why? Because you have a right to be responded to no matter what you say, even when you are hostile to the purposes the list was created for? I'm not hostile to balancing debian's composition. I'm hostile to discrimination, but I was told that wasn't a list purpose: are you saying it is? Why do you know better than others? I notice that you do not directly answer any question. I am saying tha discrimination on the basis of topic is a list rule; this is normal for nearly every mailing list I have every been on. But discrimination on the basis of the gender of the poster is not. Where has anyone been excluded because they are male? Why do you think that is the case? Because I've read the offensive messages in question, and because they were clearly off-topic for the group and manifested hostility to the list's existence and purpose. I've also seen messages from men which were sympathetic to the list's purposes, and they weren't criticized or excluded in any way. I conclude that the discrimination is on the basis of topic, and not gender. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question to all candidates.
Bill Allombert [EMAIL PROTECTED] writes: How do you see the relation between Debian and Ubuntu in the future? Note that the LWN article about the DPL election has some quotes from the candidates about Ubuntu and Debian at: URL: http://lwn.net/Articles/127031/ Your question is probably (at least partially) answered there. -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question for the Debate/Candidates
Andreas Schuldei dijo [Thu, Mar 10, 2005 at 09:41:59PM +0100]: What Muppet character do you see yourself as, and why? Swedish Chef, since i live in Sweden and love cooking! Careful - You are telling voters that if you get elected, Debian will be b0rken! Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- 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]
