IRC debate feedback
Hi All, Having just run the 2005 DPL IRC debate (and a stressful experience it was too), Martin Krafft and I would like to get feedback on what people thought of the debate and how it was run. Suggestions for future debates will be very welcome, not that I am planning to volunteer to do that again ;) I am sure that whoever does it in the future can learn from our successes and mistakes. Logs of the debate channels have already been posted by some people (thanks). The logs of all four channels will also be posted to the debian-vote pages [1] soon. An edited log of the #debian-dpl-debate channel will also be posted (this will preserve all questions and answers but will omit some of the disorganisation, to make it easier to read). Thanks again to everyone who helped make the debate work :) Helen (Posted to debian-vote to hopefully reach the IRC debate audience, but please follow up with feedback on the running of the debate to debian-project, because I think this is off-topic for the actual 2005 vote.) 1. http://www.debian.org/vote/ signature.asc Description: OpenPGP digital signature
Re: IRC debate feedback
Helen, Martin - thanks for your effort. I found the first hour basically wasted time - the strength of IRC is that it's real-time, while the form of the first hour of debate did not really use that, instead showing the weaknesses of IRC when text needs to be copied pasted around :-) The 'Questions for the Candidates' emails on -vote, together with a summary like http://debian.edv-bus.at/vote-2005/ (thanks to David for doing this!) is much better suited for this. In contrast, I very much appreciated the second part of the discussion - it was, as several of the participants said, a bit chaotic, but I think both of you started to try to lead the debate a bit more towards the end - successfully, in my view. I haven't looked at any earlier IRC DPL candidate debates, so I can't compare if this was better or worse. So long -- vbi -- Hail Eris! pgpmyy6xKI42b.pgp Description: PGP signature
Re: IRC debate feedback
On Wed, Mar 16, 2005 at 01:44:45PM +0100, Adrian von Bidder wrote: I found the first hour basically wasted time - the strength of IRC is that it's real-time, while the form of the first hour of debate did not really use that, instead showing the weaknesses of IRC when text needs to be copied pasted around :-) The 'Questions for the Candidates' emails on -vote, together with a summary like http://debian.edv-bus.at/vote-2005/ (thanks to David for doing this!) is much better suited for this. Maybe something Web- or Wiki-Based would be good for this, as mailing list discussions tend to get more verbose than intended. The strength of the first hour was that all information became available at once which made it much easier to follow than a mailing list discussion. In contrast, I very much appreciated the second part of the discussion - it was, as several of the participants said, a bit chaotic, but I think both of you started to try to lead the debate a bit more towards the end - successfully, in my view. I agree. Good work. I haven't looked at any earlier IRC DPL candidate debates, so I can't compare if this was better or worse. Earler debates may have been easier due to the lower number of participants. 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: IRC debate feedback
Marc Haber [EMAIL PROTECTED] wrote: On Wed, Mar 16, 2005 at 01:44:45PM +0100, Adrian von Bidder wrote: I found the first hour basically wasted time - the strength of IRC is that it's real-time, while the form of the first hour of debate did not really use that, instead showing the weaknesses of IRC when text needs to be copied pasted around :-) The 'Questions for the Candidates' emails on -vote, together with a summary like http://debian.edv-bus.at/vote-2005/ (thanks to David for doing this!) is much better suited for this. Maybe something Web- or Wiki-Based would be good for this, as mailing list discussions tend to get more verbose than intended. The strength of the first hour was that all information became available at once which made it much easier to follow than a mailing list discussion. I also liked the second part better. I could imagine a compromise in the middle of both schemes, for something to replace the first part; I don't know whether this is technically manageable, though. My suggestion is that only one person is allowed to speak (i.e., type and press enter) at a time. After he/she has finished, the moderator(s) hand the word over to the next person. But everybody can react on what anybody else said previously (we'll notice if someone ignores the other candidates and only answers the moderator, or only engages in disputes with candidates, ignoring when the moderators try to steer the talks somewhere else). Every candidate would have to raise their hands in order to get the word, or could choose not to speak up at a certain point. The moderators would ensure all candidates get approximately equal shares of time (or of turns, don't know). This would avoid that two or three lines of thought are totally mixed without even saying that one is talking about something different (like in # martin_krafft let's move on... [23:43] # martin_krafft It is probably safe to say that the results of the Vancouver meeting [23:43] # martin_krafft stirred the community up quite a bit. What could have been done [23:43] [...] # martin_krafft better to prevent such turbulences and potential loss of [23:43] # martin_krafft productivity? [23:44] [...] # BrandenRobinson martin_krafft: nice segue from my previous remark :) [23:44] [...] # JonathanWalther martin_krafft: I don't see any loss of productivity. The Vancouver meeting was a necessary bit of quiet time for the release managers to get together without distraction. [23:44] # AngusLees martin_krafft: it seems the meeting was arranged hurriedly for some reason. i think there was no need for such haste (the DPL election?) [23:44] # JonathanWalther martin_krafft: again, I fully support the right to freedom of association. [23:44] # AndreasSchuldei martin_krafft: then the group should try to find new members, in an active way. [23:44] # AnthonyTowns martin_krafft: Obviously, I like the idea of cutting off the flamewar where it starts to get nasty, non-technical or overly repetitive. :-/ [23:44] AnthonyTowns and Andreas Schuldei, maybe even JonathanWalther in his second sentence, clearly address older questions of Martin, and everybody different ones. Candidates could still say I agree with what A said previously, but...; to your new question, $moderator, I say that ...; As a new topic, I think X is very important, and .., but it would be much clearer. Thanks to Helen and Madduck! Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: IRC debate feedback
Marc Haber wrote: On Wed, Mar 16, 2005 at 01:44:45PM +0100, Adrian von Bidder wrote: [...] I haven't looked at any earlier IRC DPL candidate debates, so I can't compare if this was better or worse. Earler debates may have been easier due to the lower number of participants. I strongly suspect that is true. If we hope to have a wide field of candidates in future elections (and I personally think that having a variety of candidates is a good thing), we need to work out how to run a debate with that many people involved in the most effective way possible. The earlier debates that I've read [1][2][3], used variations on the format of the first half of the 2005 debate. Helen. 1. http://www.debian.org/vote/2000/leadership_debate/ 2. http://raw.no/debian/debian-debate.html 3. http://www.debian.org/vote/2003/dpl-debate.log signature.asc Description: OpenPGP digital signature
Re: Question for all candidates: Security team
* Henning Makholm [EMAIL PROTECTED] [2005-03-15 12:32]: It has been asserted on several occasions over the last few years that the security team is overworked and understaffed. This is a problem that is hard for the average developer to help with, because someone who spontaneously volunteers for the job out of the blue shouldn't be entrusted with secrets anyway. I'll leave your questions to the DPL candidates to them, but I'd like to point out that your sentence above is factually wrong - I know there is a common misconception that it's hard to contribute to security work (and this misconception makes it hard to find volunteers), but this is not true. It has been repeatedly pointed out on public mailing lists that you do not have to be a member of the security team, or even a Debian developer, to make significant contributions to Debian's security support. Most of the security work is tracking vulnerabilities, finding or backporting patches and preparing packages. Anyone can do that, and the security team has invited people to help with these tasks. Essentially, you only need a member of the security team to actually upload the source and publish an advisory, but *everything* else can be done by other people. People can: - monitor security lists - check if bugs reported there apply to Debian - file bug reports in the BTS - send patches (either by grabbing them from the security lists, from other vendors, from upstream, or by writing them) - prepare packages - draft advisories See http://lists.debian.org/debian-devel-announce/2005/03/msg00014.html (which is about testing but the same applies to stable) and http://lists.debian.org/debian-security/2001/09/msg00225.html which give more information. Furthermore, there has been a long discussion about having a database to keep better track of security issues. Matt Zimmerman (or a friend of his) wanted to work on this, but I'm not sure it ever went anywhere. If he has mails outlining what it needs to do someone could possibly implement it and thereby help the security team. Finally, there is also a Debian audit project which helps to improve security in the long run. http://www.debian.org/security/audit/ (Mail-Followup-To: debian-project since this is imho more appropriate. maybe even -security but I hope -project will get more people involved in security work) -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IRC debate feedback
On Wed, Mar 16, 2005 at 02:28:25PM +0100, Frank Küster wrote: I also liked the second part better. I could imagine a compromise in the middle of both schemes, for something to replace the first part; I don't know whether this is technically manageable, though. My suggestion is that only one person is allowed to speak (i.e., type and press enter) at a time. After he/she has finished, the moderator(s) hand the word over to the next person. Yes. This can be enforced by moving the voice tag, and greatly eased by a small $CLIENT scriptlet whch does the -v $LAST_SPEAKER +v $NEW_SPEAKER from an easy-to-type command. Maybe speaking times can also be automated by having a script automatically remove voice after the timeout expired. This is much less trouble-prone than manual de-voicing which can easily be called biased. 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: How to be debian developer
* Christoph Berg [EMAIL PROTECTED] [2005-03-15 14:12]: The baseline is: you don't ask for participating, you just do it by getting involded in the areas you are interested in. What you say is basically true. However, many Asian countries are very new to free software (open source) development and don't have an established development community yet. While they can read the documention we supply (which is fairly thorough and well done), it also helps to have a direct contact person who can answer questions and to organize practical sessions introducing interested people to ways of contributing to Debian. I've talked to people from various Asian countries at the conference in Beijing who were interested in establishing a development community and I offered to give them some help. This is just FYI. Your reply(s) were helpful already, and I appreciate them. In many cases, people don't get good pointers on how to start. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to be debian developer
* Rapid Sun [EMAIL PROTECTED] [2005-03-15 16:35]: Cambodia is new to Open Source. I am very interesting in this and some of my students want to be debian developer. Can you tell me how can we start on this? In addition to what the other people have already said, I intend to write a message with some information to the people I met in Beijing. I've been ill since returning from China, but I hope I'll find time to write the message soon. I'll send it to you too. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Release Tracking in debbugs (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
* Daniel Ruoso [EMAIL PROTECTED] [2005-03-16 14:20]: Now that Joey posted a patch to debbugs implementing the dependencies between bugs, could we think in creating a virtual s/virtual/pseudo/ A virtual package is something else. package etch, and using it to formalize and track the goals for etch? I'd say the patch needs to be added to the BTS first. ;) Also, we don't have any pseudo package for edge or release management stuff yet, so someone has to request it (and before requesting it think about how it will be used and what we really need). So the steps are: 1) [EMAIL PROTECTED] to test and apply the patch 2) someone to mail -release so they can think about the issues above -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Release Tracking in debbugs (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
* Daniel Ruoso [EMAIL PROTECTED] [2005-03-16 14:38]: Also, we don't have any pseudo package for edge or release management stuff yet, so someone has to request it (and before requesting it think about how it will be used and what we really need). That's what I'm trying to do here. But maybe I should start this discussion in -release to be more productive. Sorry, I hope my reply didn't appear as unproductive or hostile. Since your last mail was sent directly to me with a CC to the list, I thought I'd just point out that it's not me making a decision here. Anyway, I'd personally like to see more discussion about how to use this feature before actually going ahead and using it. There are the obvious use scenarios of actually using it to track real bug dependencies. I can also imagine an edge pseudo package to track some issues. However, how far should this go? Should we have a bug report for *every* issue and have 'edge' depend on it? Some projects do it like this and I think it works for them. On the other hand, we use the BTS for WNPP and I feel a specific system would be more suitable for it than the BTS (for example, using the BTS for WNPP makes it really hard to figure out when the status of a WNPP bug last changed). While I'm a great fan of proper tracking (including archival), I just wonder if the BTS is suitable, or maybe it just needs more features. For example, to keep track of tasks, it would also be helpful to have some kind of overview of the completion of a task (70% done). The BTS doesn't have this feature at the moment, maybe it should... or maybe we need some specific task tracking system. I personally haven't thought about it enough. Maybe these thoughts will lead to some discussion. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Release Tracking in debbugs (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Wed, Mar 16, 2005 at 06:03:35PM +, Martin Michlmayr wrote: Anyway, I'd personally like to see more discussion about how to use this feature before actually going ahead and using it. There are the obvious use scenarios of actually using it to track real bug dependencies. I can also imagine an edge pseudo package to track some issues. However, how far should this go? Should we have a bug report for *every* issue and have 'edge' depend on it? Some projects do it like this and I think it works for them. On the other hand, we use the BTS for WNPP and I feel a specific system would be more suitable for it than the BTS (for example, using the BTS for WNPP makes it really hard to figure out when the status of a WNPP bug last changed). For what it's worth, I feel like release issues are broad-based and heirarchical. Something necessary for release like finish d-i has multiple subtasks, and even subteams within the d-i team to manage the process. The BTS currently does not have this concept, and while joeyh's patch addresses the bug dependency issue (thanks again Joey!) it doesn't address everything to properly represent the questions. While I'm a great fan of proper tracking (including archival), I just wonder if the BTS is suitable, or maybe it just needs more features. For example, to keep track of tasks, it would also be helpful to have some kind of overview of the completion of a task (70% done). The BTS doesn't have this feature at the moment, maybe it should... or maybe we need some specific task tracking system. I personally haven't thought about it enough. Indeed. The problem with this is that adding a lot of features to the BTS while it's in use for etch may not be the wisest move. The last thing we need is having our bug system go down because we're hacking on it. I can imagine a parallel BTS which is in development and can be used for this task. As it proves its worth for tracking the release, code can be moved in to mainline. An alternate possibility is a whole new codebase that's completely independant of the BTS, but can interface with it. Things like the qa developer pages take this tactic. That's what my project intends to be, and I've been able to bootstrap it fairly quickly. It's already got the heirarchy built in, and can track teams and tasks independantly of the BTS. I still need to figure out the best way to interface it with the BTS. The obvious problem with this approach is the second system disease that joeyh talked about. The benefits are that much of the logic is moved in to rails, making it incredibly simple to add things like heirarchy and a relational DB backend. I don't know which approach is better, and for now I'm going to keep hacking on my codebase and see how it goes. Maybe these thoughts will lead to some discussion. I'm happy to see it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Release Tracking in debbugs (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
Em Qua, 2005-03-16 às 15:03, Martin Michlmayr escreveu: * Daniel Ruoso [EMAIL PROTECTED] [2005-03-16 14:38]: Also, we don't have any pseudo package for edge or release management stuff yet, so someone has to request it (and before requesting it think about how it will be used and what we really need). That's what I'm trying to do here. But maybe I should start this discussion in -release to be more productive. Sorry, I hope my reply didn't appear as unproductive or hostile. Since your last mail was sent directly to me with a CC to the list, I thought I'd just point out that it's not me making a decision here. Hostile, no, I understood that you were saying it was off-topic for -project. Anyway, I'd personally like to see more discussion about how to use this feature before actually going ahead and using it. Sure, that's why I'm starting it even before the patch is applied on debbugs and the pseudo-package is created, because, at this time, it's just a proposal. There are the obvious use scenarios of actually using it to track real bug dependencies. I can also imagine an edge pseudo package to track some issues. Yes, that's how I see it. However, how far should this go? Should we have a bug report for *every* issue and have 'edge' depend on it? I mean, every issue that afects the release as a whole, like the example I made of init setting the locale variables at boot time. Like the examples given by vorlon (gcc 4.0, python 2.4, xorg-x11 6.8.2, apt 0.6). But I certainly don't see it depending on every RC bug in the BTS. On the other hand, we use the BTS for WNPP and I feel a specific system would be more suitable for it than the BTS (for example, using the BTS for WNPP makes it really hard to figure out when the status of a WNPP bug last changed). Yes, because the huge amount of data. The tracking made for the release would be only for major issues, issues that need qualitative information more than quantitative, that's why I see debbugs as appropriate. While I'm a great fan of proper tracking (including archival), I just wonder if the BTS is suitable, or maybe it just needs more features. This points to the other concern I have, how can we know if it needs more features if we don't have almost any release tracking (I mean, more than the reports from the release team, which are great)? For example, to keep track of tasks, it would also be helpful to have some kind of overview of the completion of a task (70% done). The BTS doesn't have this feature at the moment, maybe it should... or maybe we need some specific task tracking system. I personally haven't thought about it enough. The point I'm making is that we don't need much quantitative information, but if the release team can make comments in the issues inside debbugs, pointing dependencies, more people will know what are we waiting to be ready, and then more people (who wants faster releases) can help in the specific points holding the release. That's an important step, i think. Maybe these thoughts will lead to some discussion. I hope so, as I think this tracking (or any other tracking technique choosen) should start *before* sarge release, to make it easier to keep it on track later. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Release Tracking in debbugs (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Wed, Mar 16, 2005 at 03:48:33PM -0800, Don Armstrong wrote: On Wed, 16 Mar 2005, David Nusinow wrote: The problem with this is that adding a lot of features to the BTS while it's in use for etch may not be the wisest move. The last thing we need is having our bug system go down because we're hacking on it. I can imagine a parallel BTS which is in development and can be used for this task. As it proves its worth for tracking the release, code can be moved in to mainline. There's really nothing stoping anyone who wants to work on the BTS (or things depending on the BTS) from setting up their own BTS or mirroring the BTS while they hack away. I've set up my own[1] to test my own patches... it's really not all that difficult to do. Yeah, I'm going to set my own up tonight and start poking around. If I can start implementing things on it, I'll just keep doing so. It pains me to give up rails' niceties, but I'd rather improve the BTS than start from scratch. If I find that I can't penetrate the code (which I doubt, it looks fine from what I've seen) then we'll see. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Release Tracking in debbugs (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
* Michael Banck [EMAIL PROTECTED] [2005-03-17 02:15]: Also, we don't have any pseudo package for edge or release management stuff yet, Eeek, it's 'etch' :P Doh, thanks. I see I made this typo several times (in other postings too). I think I'll be able to get it right from now on. Maybe I should be sent to the blackboard to write it a 1000 times. ;-) -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
