DPL election IRC Debate - Call for questions
Hi All, As you probably know, the 2005 Debian Project Leader elections will involve an IRC debate, to be chaired by Martin Krafft and myself. The exact format and time of the debate have not been finalised, though the debate will obviously be held during the campaign period (ie before March 21st) and the format will probably be broadly similar to those in previous years. The details will be finalised soon and announced to this list. We would therefore like to call for suggestions for questions to be put to the candidates during the debate. We hope to be able to choose a set of questions which reflect the concerns and interests of Debian Developers in general. You are welcome to either post suggested questions to this list, or to email myself and/or Martin privately with your suggestions. If you wish your questions to be anonymous, please email us privately and make that clear. Thanks, Helen. signature.asc Description: OpenPGP digital signature
Re: DPL election IRC Debate - Call for questions
On Mon, Feb 28, 2005 at 09:29:41AM +, Helen Faulkner wrote: > You are welcome to either post suggested questions to this list, or to > email myself and/or Martin privately with your suggestions. If you wish > your questions to be anonymous, please email us privately and make that > clear. Ok, i have one question. I would like to know from the DPL candidates what is their opinion on way the ftp-masters handle the NEW queue, and in particular how they handle the packages that are not really NEW : renamed binary/source packages, package split, new kernel version and new library version which need a new package upload. Do you think there is currently a problem about this, and if so what do you intent to change in this regard. With a particular interest in hearing aj's response on this one, since he has experience on this subject :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
Helen wrote: > >You are welcome to either post suggested questions to this list, or to >email myself and/or Martin privately with your suggestions. If you wish >your questions to be anonymous, please email us privately and make that >clear. A commonly-acknowledged problem within Debian is communication: * A lack of effective communications in some areas * Rude, aggressive communication dissuading contributions Is there anything that can be done on these fronts? How would our DPL candidates improve things in these areas? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "It's actually quite entertaining to watch ag129 prop his foot up on the desk so he can get a better aim." [ seen in ucam.chat ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
Em Seg, 2005-02-28 às 06:29, Helen Faulkner escreveu: > We would therefore like to call for suggestions for questions to be put > to the candidates during the debate. We hope to be able to choose a set > of questions which reflect the concerns and interests of Debian > Developers in general. Ok, here's a suggestion... * I had recently post a message to debian-project[1] suggesting that we could plan structural changes in Debian, I mean, We all know that "Debian releases when it's ready", but few people know what the "it" means. For example, if the init maintainers decide to define the locale environment variables at the boot process, many packages would break and then Debian would be far from being ready. I'm not criticizing this structural changes, but I do think that the DPL could coordinate this sctructural changes in a way more people know what it means by "when it's ready". I would like the candidates to comment on this topic. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
I know I've caused a lot of controversy with this issue but I keep reapproaching it only because I feel its so important and that we are still failing to address the issue with the proper level of seriousness (ie. completely and permanently solved). So... Dead horse... Kick. Kick. Kick. Q: In June of 2004 it became apparent that SPI had been having deep set responsibilities executing its chartered task. Donations equal to roughly half of Debian's total holdings did not make their way into the project's accounts due to poor (or non-existant) bookkeeping procedures. This failure reflected poorly on Debian when donors have to correct the accounting errors introduced. No typical business or professional organization can tolerate this type of performance in a mission critical area. As a DPL candidate, what actions will you take to insure that Debian's funds and other property are managed in a professional manner? How will you insure successful execution? On Monday 28 February 2005 3:29 am, Helen Faulkner wrote: > As you probably know, the 2005 Debian Project Leader elections will > involve an IRC debate, to be chaired by Martin Krafft and myself. > > The exact format and time of the debate have not been finalised, though > the debate will obviously be held during the campaign period (ie before > March 21st) and the format will probably be broadly similar to those in > previous years. The details will be finalised soon and announced to > this list. > > We would therefore like to call for suggestions for questions to be put > to the candidates during the debate. We hope to be able to choose a set > of questions which reflect the concerns and interests of Debian > Developers in general. > > You are welcome to either post suggested questions to this list, or to > email myself and/or Martin privately with your suggestions. If you wish > your questions to be anonymous, please email us privately and make that > clear. -- 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: DPL election IRC Debate - Call for questions
Ean Schuessler <[EMAIL PROTECTED]> wrote: [...] > Q: In June of 2004 it became apparent that SPI had been having deep set > responsibilities executing its chartered task. [...] JOOI, is "deep set responsibilities" new business-speak for problems? As past -vote readers know, I agree with Ean that this is a serious matter and think DPL candidates should consider it. Can we prod a bit at this and related topics during any IRC debate? It could link with how debian delegates are sometimes appointed for talking to other projects and sometimes documented and sometimes announced and sometimes report, apparently at random as far as I can tell. Should the DPL try QA, SLAs, anarchism or some other principle, or not worry about it at all? After first read of the platforms, the candidates look to me like the unknown, the politician, the campaigner, the teamster, the control freak and the scary. I'll let you guess who's who. Related news: at the first of this month's meetings, SPI's board started moving themselves towards meeting the standards http://www.give.org/standards/ - Here's hoping it helps. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Subscribed to this list. No need to Cc, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
Sven Luther wrote: On Mon, Feb 28, 2005 at 09:29:41AM +, Helen Faulkner wrote: You are welcome to either post suggested questions to this list, or to email myself and/or Martin privately with your suggestions. If you wish your questions to be anonymous, please email us privately and make that clear. Ok, i have one question. Can we keep the debate questions off this list? Otherwise the choice is between leaving them unanswered for a couple of weeks until the debate, or having them already answered on the list, and thus redundant for the debate. Having different Subjects for different topics would be nice too... 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. There's two reasons for this. One is the whole point of having people running a particular area is that they know what's going on; given the choice between a specialist's analysis of the problems and a generalist's, take the former. The other is that asking the DPL or DPL candidates to look for problems in the way others are doing their jobs is just asking for unnecessary conflicts: there are _always_ going to be problems in the way _every_ task within Debian is handled. The issue isn't whether there are problems, it's which problems are the most important to handle. And NEW processing doesn't even come close. and in particular how they handle the packages that are not really NEW : renamed binary/source packages, package split, new kernel version and new library version which need a new package upload. NEW is a technical term -- it means binary and source packages that are not already in the archive under that name. So those packages *are* really NEW, and that's not even a debatable question. I've already addressed this topic with my ftpmaster hat on recently, see: http://lists.debian.org/debian-project/2005/02/msg00225.html Do you think there is currently a problem about this, and if so what do you intent to change in this regard. What I am doing about it is processing packages that are stuck in NEW that are holding up higher priority tasks such as the release and security updates. Other ftpmasters are doing likewise. What I will do if elected is to support ftpmaster and other delegates in their actions so they can focus on doing useful work according to their own best judgement (which is, after all, why they're a delegate in the first place), rather than having to justify their actions in response to the latest fad complaint. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
Anthony Towns wrote: > Sven Luther wrote: > > On Mon, Feb 28, 2005 at 09:29:41AM +, Helen Faulkner wrote: > >>You are welcome to either post suggested questions to this list, or to > >>email myself and/or Martin privately with your suggestions. [...] > > Ok, i have one question. > Can we keep the debate questions off this list? Otherwise the choice is > between leaving them unanswered for a couple of weeks until the debate, > or having them already answered on the list, and thus redundant for the > debate. Having different Subjects for different topics would be nice too... Probably not, unless we make debian-vote a moderated list. I hope that the debate questioners can start from ones posed here (which may be answered by some or all before IRC) and explore in those directions a little. DPL candidates may want to keep a copy of the list archive handy and paste URLs into IRC after a short summary answer. In short, I suggest answering them if you can, but try to avoid getting into long debates (or even *gasp* flamewars). Thinking about it, I think most of the debate shows and election hustings I've seen have had a mix of prepared and unprepared questions. The only one which immediately jumps to mind as entirely unprepared was Student Union Hustings and that's not really something I'd like to see debian emulate. Of course, until Helen and/or Martin explain the debate more, I'm just throwing ideas into the melting pot. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Subscribed to this list. No need to Cc, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
Whoops. I screwed up an edit. Let me redo it: Q: In June of 2004 it became apparent that SPI had deep set problems executing its chartered tasks. Donations equal to roughly half of Debian's total holdings did not make their way into the project's accounts due to poor (or non-existant) bookkeeping practices. It reflects poorly on Debian when donors are forced to correct for accounting errors in their own business caused by our mistakes. No typical business or professional organization can tolerate this type of failure in a mission critical area. As a DPL candidate, what actions will you take to insure that Debian's funds and other property are managed in a professional manner? How will you insure successful execution? Sorry, I should have read it out loud. On Wednesday 02 March 2005 8:42 pm, MJ Ray wrote: > Ean Schuessler <[EMAIL PROTECTED]> wrote: [...] > > > Q: In June of 2004 it became apparent that SPI had been having deep set > > responsibilities executing its chartered task. [...] -- 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: DPL election IRC Debate - Call for questions
Where can we put them? Submitting them "in secret" to be edited by the debate organizers seems incorrect. I think we just need to remain focused on the idea that we are editing questions to be posed to candidates, not attempting to answer the questions themselves. On Wednesday 02 March 2005 9:41 pm, Anthony Towns wrote: > Can we keep the debate questions off this list? Otherwise the choice is > between leaving them unanswered for a couple of weeks until the debate, > or having them already answered on the list, and thus redundant for the > debate. Having different Subjects for different topics would be nice too... -- 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: DPL election IRC Debate - Call for questions
On Thursday 03 March 2005 04:41, Anthony Towns wrote: > Sven Luther 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. There's two reasons for this. One is the whole > point of having people running a particular area is that they know > what's going on; given the choice between a specialist's analysis of the > problems and a generalist's, take the former. Dear candidates! Since the DPL should be a specialist in leadership and social issues: Please discuss the social differences between debian-release and debian-kernel on the one side and the buildd admins and ftpmasters on the other side. Explain the differences in public opinion about the groups. Take the opportunity to identify other positive and negative examples for team development within Debian. [The following question is of course biased by my own opinion about the first paragraph, please feel free to ignore and/or modify this, if it doesn't fit into your argumentation.] In the light of the recent change of the NM-Queue from the second into the first group, please explain what you think caused this improvement and how (or why not) the lessons learned can (or cannot) be applied to rectifying the above identified social problem zones. Thanks for your time and your resolve to lead Debian for the next year! 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: DPL election IRC Debate - Call for questions
On Fri, Mar 04, 2005 at 01:33:15PM +0100, David Schmitt wrote: > On Thursday 03 March 2005 04:41, Anthony Towns wrote: > > Sven Luther 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. There's two reasons for this. One is the whole > > point of having people running a particular area is that they know > > what's going on; given the choice between a specialist's analysis of the > > problems and a generalist's, take the former. > > Dear candidates! > > Since the DPL should be a specialist in leadership and social issues: > > Please discuss the social differences between debian-release and > debian-kernel I absolutely don't follow you about d-r and d-k interaction ? What social difference are you speaking about, and in how far are those two groups related enough to compare them ? Especially as you below hinted at debian-kernel being on the negative side of your scale ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
Sven Luther <[EMAIL PROTECTED]> wrote: > On Fri, Mar 04, 2005 at 01:33:15PM +0100, David Schmitt wrote: >> >> Since the DPL should be a specialist in leadership and social issues: >> >> Please discuss the social differences between debian-release and >> debian-kernel > > I absolutely don't follow you about d-r and d-k interaction ? Just read the sentence to the end. For your convenience, I add some parentheses: , | Please discuss the social differences between (debian-release and | debian-kernel on the one side) and (the buildd admins and ftpmasters on | the other side). ` > Friendly, Helpful, (hopefully) Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: DPL election IRC Debate - Call for questions
[Please don't confuse my procmailrc by CC'ing me] On Friday 04 March 2005 15:45, Sven Luther wrote: > > Please discuss the social differences between debian-release and > > debian-kernel > > I absolutely don't follow you about d-r and d-k interaction ? What social > difference are you speaking about, and in how far are those two groups > related enough to compare them ? Especially as you below hinted at > debian-kernel being on the negative side of your scale ... Sorry for being hard to understand. I'll try to rephrase the paragraphs: Please discuss the social differences between teams often targetted by complaints (like the buildd admins and ftpmasters) on the one side and less complained about teams (like debian-release and debian-kernel) on the other side. Explain the differences in public opinion about the groups. Take the opportunity to identify other positive and negative examples for team development within Debian. In the light of the recent change of the NM-Queue from the first into the second group, please explain what you think caused this improvement and how (or why not) the lessons learned can (or cannot) be applied to rectifying the above identified social problem zones. I hope this is more clear. 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: DPL election IRC Debate - Call for questions
David Schmitt wrote: Please discuss the social differences between debian-release and debian-kernel on the one side and the buildd admins and ftpmasters on the other side. Explain the differences in public opinion about the groups. Take the opportunity to identify other positive and negative examples for team development within Debian. I think doing this would be actively harmful to resolving the problems in those teams. I'm not interested in having people feel the need to be defensive and worried about their participation in the project, and I don't think that kind of analysis could avoid that, especially in the context of DPL campaigning. I do hope that can be changed. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
Dear Ms. Faulkner, I read in a recent issue of Linux Magazine (European edition) that the program "Hot Babe" is being considered as an inclusion to Debian. I find this disappointing since it is a clearly sexist appllication. The defense that it should be allowed because of free expression rings hollow since anyone can download it from the internet and defending hate speech, which Hot Babe can be classified as, is not the purpose of freedom of speech. I would like you to ask the various candidates their position on Hot Babe and sexism at Debian in general. Thank you, Jeremiah Foster Gothenburg Sweden -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
also sprach Ean Schuessler <[EMAIL PROTECTED]> [2005.03.03.0735 +0100]: > Where can we put them? Submitting them "in secret" to be edited by > the debate organizers seems incorrect. Part of the reason why I would like to do it this way is (a) we have to edit the questions anyway, since there are only two hours, and about 15 submissions so far, of which many overlap. (b) the idea of the IRC debate seems to be to hear what the candidates have to say "right now" without giving them much time to prepare a diplomatic "campaign" answer. Thus, having them publicly available first changes the debate from impromptu to prepared, which makes it kind of pointless, IMHO. Anyway, if it is supposed to allow for preparation, I do not see why we cannot have a debate spread over several days on a moderated mailing list... -- 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: DPL election IRC Debate - Call for questions
Ean Schuessler wrote: Q: In June of 2004 it became apparent that SPI had deep set problems executing its chartered tasks. Hrm; from my archives of spi-private, I'd been complaining about the lack of transparency in financial mangement since 13th Jan 2003, at which point, aiui, donations had not been accepted at all for over six months. SPI members who are subscribed to spi-private and care, can probably follow: http://lists.spi-inc.org/cgi-bin/private/spi-private/2003-January/83.html [...] As a DPL candidate, what actions will you take to insure that Debian's funds and other property are managed in a professional manner? How will you insure successful execution? I think Martin's done exactly the right thing here, which is to diversify Debian's holdings on a country-by-country basis -- both because it means we're not putting all our eggs in one basket, and because it keeps the funds close to where they're going to be spent. Debian is a global organisation, and collecting all our funds in the US isn't really a very sensible thing to do, no matter how well it's managed once it's there. I've had the opportunity to help that process from the other end by my involvement in Linux Australia, Inc recently, and I'm pleased that that's already resulted in some progress [0]. Fortunately, the LA treasurer, Mark Tearle, will be doing all the actual work. :) Beyond that, though, I think SPI's problems are something the SPI board will have to work out themselves, and from what I've seen, things do in fact seem to be improving. I hope that continues. Cheers, aj [0] http://lists.debian.org/debian-project/2005/03/msg00072.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
On Tuesday 15 March 2005 06:05 am, Anthony Towns wrote: > Hrm; from my archives of spi-private, I'd been complaining about the > lack of transparency in financial mangement since 13th Jan 2003, at > which point, aiui, donations had not been accepted at all for over six > months. SPI members who are subscribed to spi-private and care, can > probably follow: > > http://lists.spi-inc.org/cgi-bin/private/spi-private/2003-January/83.ht >ml Yes. You and Branden are the only candidates who have shown a genuine interest in the financial problems. Branden is arguably in the lead from a "hands-on/work-done" perspective and you've seen how much slack I cut him. Still, I commend you for being aware and persistant. > I think Martin's done exactly the right thing here, which is to > diversify Debian's holdings on a country-by-country basis -- both > because it means we're not putting all our eggs in one basket, and > because it keeps the funds close to where they're going to be spent. > Debian is a global organisation, and collecting all our funds in the US > isn't really a very sensible thing to do, no matter how well it's > managed once it's there. I agree with your approach. It mitigates the risk of organizational failures and there are legal reasons that make it worth spreading the assets around. However, there are a number of implications to this policy. - It begins to appear that Debian is a legal entity distinct from SPI that has international monetary holdings. Either that or there are a number of legal entities which a Debian participant may choose as its "hosting authority" for legal and financial representation. In either case, there seem to be complex issues at stake that are not addressed by Debian policy. As DPL, would you assemble a finance and operations committee to address these matters and make them part of Debian policy? - We need to insure that our money is as safe in the hands of other organizations as it is in SPI's (ha ha). What standard is there for the behavior and structure of these hosting organizations? Who do they execute a binding contract with so that if someone within Debian (an organization of nebulous legal status) tells them to do something with the money they must in fact do it? > I've had the opportunity to help that process from the other end by my > involvement in Linux Australia, Inc recently, and I'm pleased that > that's already resulted in some progress [0]. Fortunately, the LA > treasurer, Mark Tearle, will be doing all the actual work. :) Excellent news. See above. > Beyond that, though, I think SPI's problems are something the SPI board > will have to work out themselves, and from what I've seen, things do in > fact seem to be improving. I hope that continues. Really, considering that Debian lost enough money to buy a multi-terabyte storage array do you honestly feel this is a "problem that will work itself out"? When a person cares enough about the project to sit down and write us a check I do not think we can fail to process those monies. A donation is the most serious contribution a non-technical user can make to our effort and that contribution deserves the highest respect. The accounting solution at SPI is still tenuous. Illness, accident or simple boredom could still easily lead us to the situation we had before. The solution you've outlined could work but it increases complexity rather than removing it. I don't know what it takes to make this clear but non-professional, volunteer accounting help is not working for Debian. It has never worked well and it is just barely working now. Shifting responsibility to multiple organizations will only create more problems unless there is some measure of quality in place that these organizations must meet. -- Ean Schuessler, CTO Brainfood, Inc. http://www.brainfood.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
Ean Schuessler <[EMAIL PROTECTED]> wrote: > Really, considering that Debian lost enough money to buy a multi-terabyte > storage array do you honestly feel this is a "problem that will work itself > out"? When a person cares enough about the project to sit down and write us a > check I do not think we can fail to process those monies. A donation is the > most serious contribution a non-technical user can make to our effort and > that contribution deserves the highest respect. This is "lost" as in "did not gain" rather as in "threw away", right? I agree that this was unacceptable. If SPI show signs of similar levels of ineptness in future, then the correct solution may well be to find someone else to take charge of our finances. However, the current board seems to have its act together to a far greater degree. > The accounting solution at SPI is still tenuous. Illness, accident or simple > boredom could still easily lead us to the situation we had before. The > solution you've outlined could work but it increases complexity rather than > removing it. I don't know what it takes to make this clear but > non-professional, volunteer accounting help is not working for Debian. It has > never worked well and it is just barely working now. Shifting responsibility > to multiple organizations will only create more problems unless there is some > measure of quality in place that these organizations must meet. Linux Australia has a significantly better track record in financial management than SPI has ever had - if the Australian dollar was worth a little more, I'd consider suggesting we should hand all our cash over to them... -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
Ean Schuessler <[EMAIL PROTECTED]> wrote: > The accounting solution at SPI is still tenuous. Illness, accident or simple > boredom could still easily lead us to the situation we had before. The > solution you've outlined could work but it increases complexity rather than > removing it. I don't know what it takes to make this clear but > non-professional, volunteer accounting help is not working for Debian. It has > never worked well and it is just barely working now. Shifting responsibility > to multiple organizations will only create more problems unless there is some > measure of quality in place that these organizations must meet. I think the accounting manpower on the SPI board is now as good as it can get, with a treasurer and appointed deputy. It's no guarantee, but I wish all board jobs had that level of cover. The kinks in finance reporting seem to be getting fixed by a bit of love from the board. When you compare SPI to peers like PDPC, they're already streets ahead on openness and accountability IMO. As I understand it, there's also work in progress to bring SPI up to "best practice" standards, identify a professional bookkeeper and sort out tax filing. Hopefully this is (will be soon?) clear in their minutes. http://www.spi-inc.org/corporate/minutes/ I hope that the next DPL will take an active interest instead of getting all "Not Invented Here" about it, but SPI has DDs involved and is responding to DD suggestions already. It would be interesting to investigate how many are aware of SPI's role and recent history, once the light you've shone is faded a little. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Subscribed to this list. No need to Cc, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
preparing the debate (was: DPL election IRC Debate - Call for questions)
also sprach MJ Ray <[EMAIL PROTECTED]> [2005.03.03.0520 +0100]: > > Can we keep the debate questions off this list? Otherwise the > > choice is between leaving them unanswered for a couple of weeks > > until the debate, or having them already answered on the list, > > and thus redundant for the debate. Having different Subjects for > > different topics would be nice too... > > Probably not, unless we make debian-vote a moderated list. ... or the candidates simply refuse to answer them here. > I hope that the debate questioners can start from ones posed here > (which may be answered by some or all before IRC) and explore in > those directions a little. We will do our best. > Of course, until Helen and/or Martin explain the debate more, I'm > just throwing ideas into the melting pot. We are working hard to (a) find a suitable time, and (b) find a suitable format. To my knowledge, Debian has never had a Debate with six candidates, and IRC is a really difficult medium to work with in terms of moderation, so we have to go through many options for a half-way optimal solution. While I am somewhat experienced with moderation (and CSCW in general), maybe some of you have suggestions about the debate. I would love to hear those *in private*, please. -- 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 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
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]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
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 effectively. 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". 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 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 [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 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]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Sven Luther wrote: 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. There are, likewise, things you can't do via NMUs -- you can't close bugs, only mark them fixed; and you can't make major changes to the package, only apply fairly basic fixes and updates. The monitoring tasks QA do can similarly be done over ftpmaster by anyone -- see Jeroen's removals page at http://ftp-master.wolffelaar.nl/removals.html eg. The "these people are MIA and need to be replaced" variant for delegates is action by the DPL instead of a random person from the -qa list, but it exists too. Also for comparison, you might consider Bug#97040 -- Adrian introduced that bug into util-linux as part of advocating that broken Standards-Version: headers should be considered release critical, and refused to fix it while it wasn't. The bug eventually got fixed some eight months later when Adrian retired from the project, and the package was taken over. 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. The release managers have pretty easy access to ftpmaster for hurrying along release issues; it's also far easier to take their word that something is a release issue than random developers. 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. Yes, that's quite true. I think the best way of breaking that cycle is killing off off-topic threads on lists; it seems both like it's not something we're going to miss too terribly, and it's something we really haven't tried yet either. 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 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. 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 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, , I guess. Anthony Towns 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 [Was, Re: DPL election IRC Debate - Call for questions]
* Sven Luther ([EMAIL PROTECTED]) [050304 21:20]: > Sure, move our archive out of the US, and be gone with the problem. except for the developers who live in US, and have to deal with export regulations by themselfs then. 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 Fri, Mar 04, 2005 at 12:18:37PM -0800, Anthony Towns wrote: > 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 > > 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. Mmm, actually, the new page would probably be a lot more usefull if it had a bit more of dynamic data in it, or let's say if the package could be separated in different subqueues, like not yet considered, being worked on, hold to keep track, and so on ... And maybe the not yet considered queue could contain some automatically calculated statistic about expected time upto consideration. Also, i hear rumors that more problematic packages get processed later, or that some choices of binary package name (like the kernel-latest-powerpc having a powerpc kernel-headers-2.6 package which may be too generic), may be a cause of a delay, while the problem is considered. I have no idea if this is true or not, but in any case, i believe the package maintainer should be in the loop for decision taking about issues of this kind concerning his 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]
On Fri, Mar 04, 2005 at 09:26:39PM +0100, Andreas Barth wrote: > * Sven Luther ([EMAIL PROTECTED]) [050304 21:20]: > > Sure, move our archive out of the US, and be gone with the problem. > except for the developers who live in US, and have to deal with export > regulations by themselfs then. So, they can vote with their feet and go work elsewhere. The IT industry is depressed in the US right now anyway. 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. 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 [Was, Re: DPL election IRC Debate - Call for questions]
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. 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. 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 ([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]
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]
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]
Anthony Towns wrote: > Matthew Garrett wrote: >> 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. One is a special case of the other. Even while NEW is being processed, there are occasional complaints that it takes too long. >> 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." But currently people have no idea what the underlying cause /is/, which is certainly a communications issue. I think this brings up another question - to what extent should teams be expected to deal with problems internally, and at what point should the project start thinking about overriding them if they aren't seen to be working adequately? We have a procedure for dealing with maintainers who don't look after their packages, but nothing similar for people with other responsibilities. (I'm not suggesting that the ftp-masters are doing their job inadequately here, just that at the moment it's hard to make that judgement - NEW may be slow because of real concerns, or because everyone capable of processing it is currently engaged in a drug-fuelled orgy of depravity. I know enough of you well enough that I assume the first, but without more communication it's not surprising that people will occasionally think that the second may be closer to the truth) >> 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. Sure. These are difficult cases, but even flagging them as "These packages will not be accepted until there is clear consensus that they should be" would be an improvement over them appearing ignored. > 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. -- Matthew Garrett | [EMAIL PROTECTED] -- 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: Anthony Towns wrote: 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 -- But currently people have no idea what the underlying cause /is/, which is certainly a communications issue. The underlying cause for the complaints is that NEW isn't being processed. The complaints are both that NEW isn't being processed and that there's no communication. 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. I think this brings up another question - to what extent should teams be expected to deal with problems internally, and at what point should the project start thinking about overriding them if they aren't seen to be working adequately? We have a procedure for dealing with maintainers who don't look after their packages, but nothing similar for people with other responsibilities. (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". And sometime's that's necessary; but it's happening _continually_, which is just tiresome and demotivating. And remember, demotivation leads to indifference, indifference leads to inactivity, inactivity leads bugs, and bugs lead to suff-er-ing. just that at the moment it's hard to make that judgement - NEW may be slow because of real concerns, or because everyone capable of processing it is currently engaged in a drug-fuelled orgy of depravity. The sentence "I'm not suggesting that the ftp-masters are engaged in a drug-fuelled orgy of depravity" seems conspicuous in its absence... (Although, given James T. was out partying all last night with Steve L., maybe that's not so unreasonable...) I know enough of you well enough that I assume the first, but without more communication it's not surprising that people will occasionally think that the second may be closer to the truth) TTBOMK, there are no greater concerns with the packages in NEW now than there were, say, four months ago. Each of the ftpmasters have just had higher priorities, within or outside of Debian, than processing the queue. 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. Sure. These are difficult cases, but even flagging them as "These packages will not be accepted until there is clear consensus that they should be" would be an improvement over them appearing ignored. Not really -- the question then becomes "How do you get that consensus?", and that's hard -- if it weren't we'd have already replied "REJECT: Your package has these problems, please fix them." The question's then immediately, "How do we deal with the followup question?" and there's no real answer to that. There was a similar issue with the crypto-in-main question -- when the crypto regs changed, we spent ages wanting to integrate crypto into our OS, but not quite knowing how. Eventually, we got a group together to look seriously at the issues, and work out what really was feasible, and did it -- but that involved finding a specialist lawyer we respected, having a few iterations working out all the potential problems and how we'd address them, and a lot of time and effort, particularly on behalf of ftpmaster. And that's *with* a specific "crypto-in-main" team made up of non-ftpmasters. That's time and effort that's not available now even for *standard* NEW processing. It'd be possible to prioritise increased communication, but that's YA thing to do, leaving less time for even the things that're currently being done. 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. There are various scales of "awkward", ranging from "we might get sued if we accept this, and we'v
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 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 [Was, Re: DPL election IRC Debate - Call for questions]
On Sun, Mar 06, 2005 at 11:28:57AM -0800, Anthony Towns wrote: > Matthew Garrett wrote: > >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. > > There are various scales of "awkward", ranging from "we might get sued > if we accept this, and we've no idea if we'd even have the law on our > side" to "gag, that's one long copyright file, I might read that after > breakfast instead". None of the packages are being ignored though. The uploader of the package is mostly being ignored though. > 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. 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]
Op za, 05-03-2005 te 08:48 +0100, schreef Sven Luther: > 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. You're making a fool of yourselves. The information isn't being actively fed to the NSA; it's being actively fed to a database housed in some administrative building owned by the US department of finances, or something like that. Even if it were; do you really think "the NSA or whatever" doesn't already have a file on many Debian Developers, even without the information being actively fed to them? -- 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 [Was, Re: DPL election IRC Debate - Call for questions]
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? -- 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 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. As others have said, I don't think there's any right to expect an individual to justify why they haven't been doing something. However, I do think that there's an expectation that teams ought to say why things aren't being done. "People are busy" is an entirely acceptable answer, but instead we have rumours of the release team asking for NEW processing to stop. I don't think that benefits anyone. >> I think this brings up another >> question - to what extent should teams be expected to deal with problems >> internally, and at what point should the project start thinking about >> overriding them if they aren't seen to be working adequately? We have a >> procedure for dealing with maintainers who don't look after their >> packages, but nothing similar for people with other responsibilities. >> >> (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". And > sometime's that's necessary; but it's happening _continually_, which is > just tiresome and demotivating. No. I don't believe that the ftp-masters are doing their job inadequately. However, that doesn't mean that we should ignore any situation where a team /does/ do their job inadequately. At what point do we (as a project) step in and do something, and how do we deal with that sort of situation without demotivating other teams? I think these are difficult questions, but I think we need to find answers to them. If a single group of people did significantly decrease the productivity of the rest of the project for no good reason, I hope you'd agree that something should be done. The fact that people are volunteers doesn't mean that they can shirk responsibilities - if they do, that responsibility has to be passed on to someone else. >> Sure. These are difficult cases, but even flagging them as "These >> packages will not be accepted until there is clear consensus that they >> should be" would be an improvement over them appearing ignored. > > Not really -- the question then becomes "How do you get that > consensus?", and that's hard -- if it weren't we'd have already replied > "REJECT: Your package has these problems, please fix them." The > question's then immediately, "How do we deal with the followup > question?" and there's no real answer to that. Telling people that there is inadequate consensus about a package means that they can either accept that they're not going to get that consensus, or alternatively start doing something about gaining that consensus. Failing to tell them that just leaves them puzzled. It's not the job of the ftp-masters to gain that consensus, but I think it /should/ be their responsibility to tell people that they don't think it exists. > It'd be possible to prioritise increased communication, but that's YA > thing to do, leaving less time for even the things that're currently > being done. Sure. How can that be improved? > 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 > discussions affect ftpmaster, I'm pretty reluctant to want to inflict > them on anyone else. I've no grudge against ftpmaster. I think there are various teams within Debian that could better communicate their activities, and my platform makes it clear that I want to improve that. At the same time, I want to work on reducing the entirely pointless complaints made against teams at various points. As you point out, flamewars do nothing to improve motivation or productivity. -- Matthew Garrett | [EMAIL PROTECTED] -- 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 [Was, Re: DPL election IRC Debate - Call for questions]
On Tue, 08 Mar 2005, Sven Luther wrote: > 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). Nothing in debian-legal has said anything like this at all.[1] Compliance with the regulations of the country that a large portion of the infrastructure is located within is nothing new, and has little or nothing to do with the DFSG freeness of the software at hand. [In fact, this is something that almost all mirror operators have to deal with in almost every country, as many countries have stupid and pointless laws dealing with works that are "weapons", "hurt children" or "offend $DEITY|$INTEREST_GROUP".] Don Armstrong 1: Feel free to list specific messages refuting this, but considering that I've read almost all of the messages sent to -legal in the past few years, I should have remembered. [If only because I would have had to engage the flamethrowers at maximum and engage in deadly battle to cleanse such arbitrary linkage of stupid governmental regulations to things that matter, like software freedom.] I mean, my memory is bad, but I haven't replaced my brain with a large container of carbonated soda water, rumors to the contrary and my dietary intake of said beverage notwithstanding. -- "For those who understand, no explanation is necessary. For those who do not, none is possible." http://www.donarmstrong.com http://rzlab.ucr.edu -- 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: (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". And sometime's that's necessary; but it's happening _continually_, which is just tiresome and demotivating. No. I don't believe that the ftp-masters are doing their job inadequately. I didn't say you believed it -- I said you were suggesting it. Which is worse, because it's not something that can be addressed straight up, because you'll just say "But that's not what I /meant/". But how else do you think "Oh, NEW's not being processed! There's not enough communication. And we need to work out how to deal with inadequate teams, anyway." is going to appear to anyone at all? Heck -- any rumours that the NEW is deliberately stopped because of the release presumably started when that was explicitly denied by the RM; how much easier is it for your sequence of thoughts to get misconstrued to "I think ftp-masters are doing their job inadequately and must be retrained/replaced." ? However, that doesn't mean that we should ignore any situation where a team /does/ do their job inadequately. That doesn't mean we should ignore the possibility of aliens orbiting the planet trying to hack their way into Debian, either. Are there any teams doing their job "inadequately"? If not, shouldn't the whole issue be treated the same as the space aliens one, who I presume we're confident don't exist either? If there are teams doing their job inadequately -- and you've explicitly said you don't think that's the case for ftpmaster -- why are you attaching this discussion to one about ftpmaster? If you don't think ftpmaster is the most inadequate team in Debian at present, why are you contributing to the false perception that they are by participating in this thread? At what point do we (as a project) step in and do something, and how do we deal with that sort of situation without demotivating other teams? I think these are difficult questions, but I think we need to find answers to them. At what point do you see sufficient requests from a team for support, and respond to them? Not really -- the question then becomes "How do you get that consensus?", and that's hard -- if it weren't we'd have already replied "REJECT: Your package has these problems, please fix them." The question's then immediately, "How do we deal with the followup question?" and there's no real answer to that. Telling people that there is inadequate consensus about a package means that they can either accept that they're not going to get that consensus, or alternatively start doing something about gaining that consensus. No, then they'd start mailing lists asking for "support" -- which isn't gaining consensus or resolving the underlying issues. What needs to happen is the underlying problems need to be brought to light, then addressed directly: the problem here is that the underlying problems aren't even clearly known in the first place. And the package maintainers are usually the /worst/ people to be doing this, because by the fact that they've decided its worth packaging, they've usually already concluded, explicitly or implicitly, that the problems aren't worth taking seriously. Failing to tell them that just leaves them puzzled. It's not the job of the ftp-masters to gain that consensus, but I think it /should/ be their responsibility to tell people that they don't think it exists. Do you think explaining that should take priority over the activities ftpmaster are currently prioritising, and if so, which ones? For comparison helping the crypto-in-main team get a consensus about that problem took something like three or four months of my time as RM/ftpmaster -- and that was with explicit support and activity from the DPL, a team of people working on the problem, and a lawyer whom we could contact fairly easily. It'd be possible to prioritise increased communication, but that's YA thing to do, leaving less time for even the things that're currently being done. Sure. How can that be improved? 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? I've no grudge against ftpmaster. Then how about doing the courtesy of not using ftpmaster as a perfect opportunity to discus
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 [Was, Re: DPL election IRC Debate - Call for questions]
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. I can't see why one would make the jump from 1 to 2 without more knowledge of ftpmaster's curent situation than most DDs usually have. I think a jump to "(2) This isn't a high enough priority to be addressed now" is more likely and results in a different track. If you don't like that, the way to change it is information, IMO. I don't think your second train of thought is likely, nor the one we've seen often, unless you see anyone concluding that they disagree with your priorities as "Oh, that's right, because they're in the Cabal and don't care about us peons. Bastards." -- 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: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 [Was, Re: DPL election IRC Debate - Call for questions]
On Tue, Mar 08, 2005 at 06:09:00AM -0800, Anthony Towns wrote: > > (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. (4) I'll ask. (5) Hmmm, no response. OK, let's see whether anyone else knows. (6) Oh, hey, at least someone who isn't on the ftpmaster team could give us a strong reason to believe that (2) really is accurate. But that just puts us back at (3), with a little more information. (7) Oh, hey, I've got an idea that might be able to help. (8) (This is the stage at which ftpmasters, if they say anything at all, both deny that there is a problem and give every appearance of rejecting the proposed methods of helping, without proposing alternatives). A lot of times we don't even get to (2); going instead to (2b), someone assumes it's the Cabal, or whatever. Answer? Better information flow. Sometimes we don't get past (5), or (5) flows back to (2b). Frequently, (5) triggers a flamewar, even if it doesn't flow back to (2b). It's been said that ftpmaster isn't a good example of a team failing to communicate, and that others are the issue; I would challenge that assertion. I think that the ftpmaster team *is* an excellent example of, at the very least, "perceived to be uncommunicative in a way that causes problems or frustration to many people". Maybe they communicate great with some set of folks, but my personal experience has been rather less than stellar, and the number of private emails in my Debian inbox from people saying "I'd second you but I'm not willing to risk for speaking out in public right now" (where X is "Not making it through the NM queue", "My packages will be deliberately delayed", "The entire ftpmaster team will hunt me down and beat me with wet noodles", whatever) would indicate that this isn't *just* me. Maybe the number really is small, but if so, why is it so frequent to get random questions about this on the lists every month or so, *from different people*? However, if anyone has a team that is a *better* example to discuss, please point it out. I'm all for "worst goes first" as a general method of problem triage. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Tue, Mar 08, 2005 at 04:54:34PM +0100, Sven Luther wrote: > 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. Here is the relevant section of the .changes file for the package in question: Date: Wed, 12 Jan 2005 17:40:59 +0100 Source: kernel-latest-powerpc [...] Changes: kernel-latest-powerpc (101) unstable; urgency=low . * Typo in debian/control created kernel-headers-2.[46]-powerpc instead of kernel-headers-2.[46]. Fixing this means another wait in the NEW queue :( This merely underscores the contrast between Anthony's recommendation -- being resourceful enough to find a way to achieve the things you care about when no one is interested in helping you -- and what you've done in this case -- whine that a name change on *headers* metapackages that are used nowhere in the installer prevented you from improving the quality of that installer. And with all that, the kernel-latest-powerpc package is still in an RC broken state, because you chose to make a last-minute reorganization of kernel-patch-powerpc-2.4.27 without updating kernel-latest-powerpc to match. You can hardly blame the ftpmasters for this state of affairs. > 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. Frankly, looking at the frequency and timing of some of your package name changes, I think having ftpmaster oversight here is a very, very good thing. None of this is on-topic for -vote, but I felt the outlandish claims that ftpmasters were causing delays for d-i RC3 should not be allowed to stand unchallenged. If you really feel compelled to argue about this further, please take it to debian-devel, where explanations of why gratuitous package name changes are bad are on-topic. M-F-T set accordingly. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
also sprach Anthony Towns [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 [Was, Re: DPL election IRC Debate - Call for questions]
On Tue, Mar 08, 2005 at 03:11:02PM -0800, Steve Langasek wrote: > On Tue, Mar 08, 2005 at 04:54:34PM +0100, Sven Luther wrote: > > 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. > > Here is the relevant section of the .changes file for the package in > question: > > Date: Wed, 12 Jan 2005 17:40:59 +0100 > Source: kernel-latest-powerpc > [...] > Changes: >kernel-latest-powerpc (101) unstable; urgency=low >. > * Typo in debian/control created kernel-headers-2.[46]-powerpc instead of >kernel-headers-2.[46]. Fixing this means another wait in the NEW queue > :( > > > This merely underscores the contrast between Anthony's recommendation -- > being resourceful enough to find a way to achieve the things you care about > when no one is interested in helping you -- and what you've done in this > case -- whine that a name change on *headers* metapackages that are used > nowhere in the installer prevented you from improving the quality of that > installer. It was a damn typo i oversighted in the 100 version. And the mention that itmeans a wait in the NEW queue was in no way a whining, but an informative mention to whoever would look in the svn archive for the package wondering why this problem (which marked kernel-latest-powerpc uninstallable for almost two month) was indeed solved and waiting in NEW. and notice that these packages are not used on powerpc because Kamion didn't modify base-installer to use them, while they are used (unless i am mistaken) in the x86 case, and in general are meant to be used, which makes changing kernel possible without rebuilding the base-installer .udeb, and thus allows more flexibility. Notice also that the metapackages in question where ones transfered from wheree Jens had put them, namely in the kernel-images themselves, which caused lot of breakage as you well know once we had more than one kernel version in the archive. I mentioned this fact to Kamion, and he told me he would not bother ftp-masters about this, since the packages name where to generic for his, and dismissing my argument that these where the names of the kernel-header metapackages previously used. I also wrote an email to ftp-masters explaining why it was important that this package got processed to the d-i release schedule, and also mentioning 2.6.10 whihc was a potential release candidate, that email was helpfull and nice, but i got nil reply to it. And i think that this is the real problem here, any mention of the NEW queue is seen by the ftp-masters and others involved like whining, and there is a knee-jerk reaction to fully dismiss the issue as far as possible then, while it may well be some half humorous attempt to get over the frustration of it or just be informative. > And with all that, the kernel-latest-powerpc package is still in an RC > broken state, because you chose to make a last-minute reorganization of > kernel-patch-powerpc-2.4.27 without updating kernel-latest-powerpc to match. > You can hardly blame the ftpmasters for this state of affairs. Nope, i uploaded the fix. it's in NEW again i think, let me check. Ah, no, they where accepted on march 5, please check your sources before making such aggressive claims. And you can't really take the argument both way, in one saying that the ftp-master are volunteers and work on things as their time allows, and on the other side imply that the rest of the developers are just slaves to be held to thight release schedules. > > 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. > > Fran
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Tue, 8 Mar 2005, Sven Luther wrote: > > > 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. Any new binary will have to pass NEW. Having to do notifications doesn't change that(and that's an automatic process, anyways). > 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. Notifications are always done, anyways. See -devel-changes. > 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). Only if every developer had to do it themself. But this notification is automated. > 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 ? I am not aware of there being a reject procedure in place. > So, you want to go into DFSG flamewar, please go ahead. Understand how the system works first, which you don't seem to. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
