Re: Results of the Lenny release GR
Robert Millan r...@aybabtu.com wrote: On Mon, Jan 12, 2009 at 07:13:57PM +0100, Michael Goetze wrote: Robert Millan wrote: - Even if there's a general perception that everyone agrees not to delay Lenny at all costs, this should definitely be voted on and sanctioned. Not doing so creates a very bad precedent. You think everyone must be voted on? Everything significant, yes. Because I believe in democracy. You mean grassroots democracy. Which won't work in pure form in a group of 1000 people living dispersed all over the world. Elements of it work quite well, that's why we have GRs. But we do need, and we do have other ways to live our democracy. Regards, Frank -- Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
Robert Millan r...@aybabtu.com wrote: 4- Bugs which are trivial to fix, such as #459705 (just remove a text file), #483217 (only affects optional functionality that could be removed according to the maintainer) Of course it could be removed, and it's technically trivial. The question is whether it is worth the disadvantages to our users, when we still expect (or hope or something in between) that the files will be released under a DFSG-free license once we manage to attract enough attention from Donald. Regards, Frank -- Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: General resolution: Clarify the status of the social contract
Manoj Srivastava sriva...@debian.org wrote: Given that, I suggest we have a series of proposals and amendments, each in a separate email, sponsored and seconded independently, that could look something like this below: ,[ The Social contract is a binding contract ] | The developers, via a general resolution, determine that the social | contract should apply to everything Debian does, now and in the future; | _AND_ the social contract should stop us from including anything that | doesn't comply with the DFSG in main ` Sorry for stepping in so late - I simply don't have time to read all those mails. What you seem to have forgotten an option like ,[ The Social contract is a binding contract ] | The developers, via a general resolution, determine that the social | contract should apply to everything Debian does, now and in the future; | _AND_ the social contract should stop us from including anything that | doesn't comply with the DFSG in main , _AND_ the social contract should stop us from releasing anything that doesn't comply with the needs of our users ` Which makes it clear that this is a bogus discussion: As long as our priorities are our users AND free software, we cannot let only one of both make the single criterion for our actions. Even an option like this: ,[ The social contract is a goal, not a binding contract ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract is an aspirational document: while we aim to achieve as | much of it as feasible at all times, we don't expect to get it | completely right for some time yet. This includes DFSG-freeness of all | firmware ` is still focussed on free software only, and also feeds the illusion that in some time point in the future we would have sorted out all issues with software freeness (and will only then start to tackle this other thing, users?) I think we need this clarification, so people no longer accuse other people of malfeasance based on a flawed understanding on the correct status of foundation documents. I am sure this wouldn't help at all, except if we'd vote for the first option, which I believe would mean forking: Orthodox Debian which never releases, and a derived or related distribution which would be comparable to Debian as it is. Regards, Frank -- Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Kalle Kivimaa [EMAIL PROTECTED] wrote: Would it be a good compromise between SCs #1, #3 and #4 if we made an exhaustive list of non-free bits in main, and make it our goal that the list gets smaller between each release and not to add anything to that list? The last part of the sentence is unrealistic, because the list would only describe the *known*to*be* non-free bits. There are unknown non-free bits already in the archive[1], and there might be some that slip in by new upstream releases. Regards, Frank [1] Our up-upstream has recently started a license auditing and found several, just look at texlive's most recent RC bugs -- Frank Küster Debian Developer (TeXLive) ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal - Use Cases
Anthony Towns [EMAIL PROTECTED] wrote: == Upstream Maintainers == [...] Authorised by: Existing maintainer Notes: package should be co-maintained by maintainer and upstream, upstream generally to be expected to be uploading code changes rather than packaging changes I'm not sure I agree with the note. Of course it makes sense to upload a new, say security-fixed minor upstream version with identical packaging. But that's mostly easy for active DD maintainers, too. The really interesting case would be an application with some Debian-specific changes and a fruitful discussion how the upstream code and build/install system could cater for distributors' needs. Here the upstream author could learn from Debian, and make the changes needed to adapt to improvements in upstream packaging (like, switching from a large patch or hack to the newly added configure option). However, like Pierre, I'm not convinced that the numbers of actually interested people is large. I also have one more possible use case, again without an idea about numbers: == Team Members == In a packaging team consisting of DDs and non-DDs, it would be helpful if some non-DDs could get upload rights. In the Debian TeX team, a couple of times we've encountered situations where the required fix for an important or RC issue was obvious (already in the repository, or a trivial patch), but the DD members were busy/offline/had their local copy switched to an utter mess of mixed branches. It would be great if the non-DD, but DM-members could make an upload in such a case. I'm not sure, though, that *our* team members would be very open to that. I could ask, if you like. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: %20Re: Debian Maintainers GR Proposal
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: - then I am granted the right to help fixing the bug I found a few months ago No, you don't have to do that to help fix the bug. To help fix the bug, all you have to do is post a patch on the bug log. Which is what he did. If you think the patch is being neglected, ask about it on debian-qa. Which could have sped up the fixing of the bug as well as removal of the package... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: %20Re: Debian Maintainers GR Proposal
Benjamin BAYART [EMAIL PROTECTED] wrote: So here was my practical conclusion: I did send a bug report, useless during months, and that bug report was used to argue that the package is broken and unkaintained and to remove it. Conclusion: reporting on a un-maintained package is something dangerous. Hm, what was the severity of the bugs you are thinking about? Where the packages removed due to a couple of unfixed important bugs? There was two kinds of bugs in the package: - the one I reported, with a patch (segfault on some cases introduced by modern TeX uses) - bugs about Debian (version of the standards, version of dh_*, etc) Of course, the bugs about Debian were regarded as very serious, and were the reason for being a candidate to removal. From a user point of view, it sounds like crazy. I'm not sure what you are talking about exactly, and which package was a candidate for removal. dvidvi had a debhelper-related bug (#168387), but this was not just about a version, it failed to build from source. This is something we cannot tolerate in a stable release. An outdated standards version doesn't make a package a candidate for removal AFAICT. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Debian Maintainers GR Proposal
Benjamin BAYART [EMAIL PROTECTED] wrote: So, right now, when I have troubles with Debian/TeX stuff, I tend to solve it on my computer, and just report nothing, since reporting is useless. I disagree since when you report a bug and even contribute a patch and add links to your own fixed packages other users can benefit from your investigation as well -- given they find the bug report and the patch/link included. This is not what I learned from previous experiences. And I trust my experience more than any theory. The exemple of dvidvi was quite a mess, the package was a candidate for removal, and I did ask personaly to DDs to give help in using my patch, cleaning the mess (Debian standards evolved while the package did not), and to upload it. I guessthis experience is quite the same as others make, at least for TeX packages. So here was my practical conclusion: I did send a bug report, useless during months, and that bug report was used to argue that the package is broken and unkaintained and to remove it. Conclusion: reporting on a un-maintained package is something dangerous. Hm, what was the severity of the bugs you are thinking about? Where the packages removed due to a couple of unfixed important bugs? I think that Debian users are generally better served when the number of available packages is limited, but their quality is high, instead of a large number with often questionable quality. This is particularly true for software which is hardly maintained upstream; I guess dvidvi is an example for that: Since I started using TeX seriously, around 98 or 99, I've never been given advice to use it (I use ps* or pdfpages instead). If it's being maintained badly within Debian, is there much use in keeping it? Those with old installs can keep their old version, those with new ones should probably rather learn those tools that are currently developped. The only problem is if a long-term user gets a new machine... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Debian Maintainers GR Proposal
Raphael Hertzog [EMAIL PROTECTED] wrote: On Fri, 22 Jun 2007, Thijs Kinkhorst wrote: You say you knew several, so maybe you can give some details as to their reasons for this. Yes, I already explained this I guess in some former thread. I know Benjamin Bayart, who's a TeX expert and who uses some TeX packages and tools that got removed from the archive due to lack of maintainer. He doesn't want to to be DD for all the reasons already explained but he cares about those packages and has the skills required to maintain them. I don't know which packages you are talking about, but I must say that I am not aware of anyone posting patches to RC bugs of TeX-related packages, except the usual suspects. I'm surprised to hear that there is someone who is interested in them. Moreover, if those TeX tools are free, the best approach would be to integrate them (upstream) into TeXlive, and they'd end up in Debian by the next release with minimal required Debian maintainer work. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Debian Maintainers GR Proposal
Thijs Kinkhorst [EMAIL PROTECTED] wrote: On Sunday 24 June 2007 16:48, Benjamin BAYART wrote: not to go through NM just to upload a fix or two every year. I find it hard to believe that you cannot find a sponsor to upload a fix around twice a year. Have you tried to ask the Debian TeX maintainers for this? Or the debian-mentors mailinglist? I must admit that I might have refused to make an upload of one of the packages Benjamin suggested, even if he sent it to the mailing lists, for a combination of a couple of reasons: - I don't know him (yet), so I wouldn't have trusted his patch and packaging, but instead would have to look closely at the package just as if I was doing the NMU myself - I currently have the feeling that we shouldn't keep old TeX-related, hardly maintained packages alive, but instead either kick them out or integrate them into TeX Live - I don't have much time frequently Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Debian Maintainers GR Proposal
Benjamin BAYART [EMAIL PROTECTED] wrote: In the TeX team, or in relation with TeX team, are some great experts, and I do interract well with them when there is an opportunity. By the way, what is done now in the combination of TeXlive and Debian is very close to (and seem to take some ideas from) concepts I did present in a TUG meeting at Oxford in 2000. Interesting - is that talk available somewhere? Neither www.tug.org nor uk.tug.org seem to have it. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Debian Maintainers GR Proposal
Raphael Hertzog [EMAIL PROTECTED] wrote: On Fri, 22 Jun 2007, Marc 'HE' Brockschmidt wrote: Anthony Towns [EMAIL PROTECTED] writes: * multiple Debian developers have requested the individual's removal for non-spurious reasons; eg, due to problematic uploads, unfixed bugs, or being unreasonably difficult to work with. This part is broken and shouldn't end up in a final proposal. We need to decide on actual rules, otherwise this can lead to endless flamewars. We take non-binary decisions every day (MIA, hijack, etc.). This is just one more of those. Usually it's pretty clear when someone isn't up to the task. If you have some concrete rules, I'd be happy to discuss them, but at this point I don't think that concrete rules would help (age of RC bugs? bug severities can be discussed, changed. only 3 maintaineres unhappy instead of the 4 required? what if those 3 are the Gnome maintainers and the package is a Gnome one?). The concrete rule is in the next paragraph: * the Debian Account Managers have requested the individual's removal for any reason. So those multiple DDs just approach the DAMs which make the decision. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
How does NM work? (was: Debian Maintainers GR Proposal)
MJ Ray [EMAIL PROTECTED] wrote: The main things tested by NM now seem to be tolerance of boredom, stupid questions and poor social skills of DDs, along with the ability to paraphrase from key docs, which are not really key indicators of who will be a good DD. When I passed NM in early 2003 (I think), it was completely different to that. Can you point me to the information what has changed? Or may it be that this depends very much on the AM? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Proposal: GR to deal with effects of a personal dispute
MJ Ray [EMAIL PROTECTED] wrote: 1. Sven Luther is suspended from all debian lists for a year, which should be similar to (b), because the project generally liked his two-month self-suspension and wishes not to receive his discussion contributions at the moment. [...] 3. Sven Luther is reinstated as a full developer, reversing (a), because the project wishes to receive his technical contributions. It seems with 1 in operation, he cannot act his developer Powers according to constitution 3.1, numbers 2 propose or second draft General Resolutions and 3 propose themselves as a Project Leader candidate in elections. Number 3 (as well as seconding in 2) could be easily resolved by requiring him to do that through a personal relay. For proposing a GR, I see neither a simple technical solution like this, nor anything else, because of the fear of a GR DOS attack. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Q 2 all candidates: Usage of [EMAIL PROTECTED] and [EMAIL PROTECTED]
Anthony Towns aj@azure.humbug.org.au wrote: In general, if someone else is in charge of something -- like Joey and press stuff -- and you don't want to work with them, I think it's better to do things independently rather than fight over the infrastructure. I think this attitude is exactly what causes the infrastructure problems in Debian. don't want to work with them is just an other way to express don't want to work exactly the way they used to work in the past, and in fact any addition to a team will and should change the way things are done. So this means that either nothing happens, or we create duplicate infrastructure - not because the new thing serves a different purpose, just because the old is occupied. I think instead we should try to cooperate and find solutions that address the concerns of all involved, and reuse existing infrastructure. (By the way, this is not specific to the press/news issue - in fact I personally have never found that to be a problem, and I've found Joey someone with whom it's generally fun to work with.) Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Question to the candidates: inclusion of the kFreeBSD-* ports
Josselin Mouette [EMAIL PROTECTED] wrote: Le dimanche 04 mars 2007 à 18:13 +1000, Anthony Towns a écrit : But what I mean is more that maintaining two simple Debian patches (one for Linux, one for kFreeBSD) is probably simpler than maintaining one complicated Debian patch (with some conditional make cruft). BWHAHAHAHAHAHAHAHAAHA. Sorry, but reading this just makes it obvious - to those who didn't already know it - that you have not been doing serious maintainer work lastly. That, or the fact that the reality he believes in is formed by his opinion, not by perceiving what happens outside. This leads to the creation of ugly hybrids as dunc-tank. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Questions to the candidates
Steve McIntyre [EMAIL PROTECTED] wrote: [ First of all, apologies for the delayed response; I'm catching up after several days of FOSDEM-plague :-( ] Hi Mike, On Sun, Feb 25, 2007 at 09:50:41AM +0100, Mike Hommey wrote: Hi, These questions may be skipped by AJ, because the answers are obvious. What do you think of the dunc-tank initiative ? What do you think are the result of the experiment ? I think that dunc-tank was a very good idea on the part of AJ, a DPL looking for new ways in which to help the release process. I'm confused. In your other mail you wrote , | My belief is that the DPL hat is something you can take off. Of | course, the DPL must be very explict in this, but if I take the | dunc-tank issue, which sparked my question, I think aj handled it not | that badly. Maybe he could have been more clear but he most certainly | had the moral right to be involved in dunc-tank. ` So do you think he was doing it as DPL looking for new ways, or as a DD? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Questions to the candidates
Kalle Kivimaa [EMAIL PROTECTED] wrote: Frank Küster [EMAIL PROTECTED] writes: I'm confused. In your other mail you wrote I think you find that *I* wrote what you quoted after this. Uups, sorry. I was really confused. Just forget about it. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Questions to the candidates
Raphael Hertzog [EMAIL PROTECTED] wrote: Please drop this, you know the history as well as everybody. Anthony started the discussion with his DPL hat because he wanted to do that within Debian. After discussions, he decided to continue that experience outside of Debian as DD. One can discuss how much he succeeded at that, but the distinction between the initial idea launch as DPL and the setup as DD should be pretty clear to any DD who followed the story. I have followed the story, still to me it seems pretty clear that the distinction is extremely blurred, at best. I have not been among the prospective sponsors that dunc-tank asked, so I don't know whether or how he informed that he was not doing that as the DPL. But that even doesn't matter too much. First of all, I think the fact that he is DPL will influence the other party's decisions as soon as they know about it, no matter what hat he is explicitly wearing. Second, I believe that anyone who is in a political or management role that gives him power to influence something *within*some*constitutional*limits*, then he really should accept these limits and not try to pursue the same aims as a private person in parallel. As a real-life example for this, I think a prime minister should not be the owner of the near-monopolian TV and newspaper company in the same country. Similarly, the DPL should not be on the board of an external group that tries to influence Debian's inner workings, with money or anything else. [Need I stress that I do not want to compare our DPL with Berlusconi? I'd oppose any of these mixed-roles no matter whether I like the aims that the respective people pursue or not. I'm only giving two examples for my general rule of separating internal and external infuences] Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Questions to the candidates
Simon Richter [EMAIL PROTECTED] wrote: Do you feel that the DPL is first and foremost The Debian Project Leader, in the sense that anything Debian-related the DPL does, he does so as the DPL, not as a DD or a private person? Both. Foremost, the position of the DPL is a hat that can be put on if needed, and shouldn't be put on if there is no clear need for it, however it is also important that the person below the hat still has the trust and respect of the others. The DPL can only mediate as long as he is deemed impartial, and this is a highly subjective judgement in which the wearing or non-wearing of hats only plays a minor role. Do you not see the problem that people might view the DPL's hat on top of the DD's head, even if the DD think's he isn't wearing it? I think this is the main issue people have with dunc-tank: By paying people to perform some task in Debian, we'd effectively acknowledge that it is necessary to pay them, otherwise we wouldn't. However if this is the case, then it is not a once-off thing, but will be recurring every year; claiming otherwise asks the question of why this particular incident is different and should not be seen as a precedent. I cannot speak for people, but for *me* this is not the main issue. Personally, I was pretty undecided with respect to paying the release managers. I am *really* angry, however (always must hold myself back from writing this other four-letter-word with 'u' when spelling dunc-tank), about the fact that our DPL, as soon as he felt the wind blowing in his face, turned his back on the project and founded dunc-tank, out of the control of the project, but with unclear boundary to it, and with him juggling with DPL, DD and personal hats. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Question to the candidates: inclusion of the kFreeBSD-* ports
Anthony Towns aj@azure.humbug.org.au wrote: Personally, due to things like [0], I tend to think having different sources for different OSes is likely to make sense; which isn't something we can manage with the main archive as it stands. Cheers, aj [0] http://lists.debian.org/debian-devel-announce/2005/06/msg00012.html I'm puzzled. The mail you cite explains a really simple way to make a source buildable with SElinux on linux, and without on other OSes. How can you take that as an argument for separating the archives? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Questions to all candidates: Release importance, release blockers, release quality
Steve Langasek [EMAIL PROTECTED] wrote: [to Sam Hovecar] If you think there's a usual two-month buffer that applies to release date targets, why, before we'd even reached the original target release date, were you publicly mocking the release team's efforts in your blog? I appreciate your support as a maintainer in dealing with release-critical bugs that affected your packages. But why should anyone who cares about Debian's stable releases vote for you if that's the sort of support you're going to show for the release team as a public figure? Hm, which blog entry are you speaking of? Currently, the oldest one I find on http://sam.zoy.org/blog/ is from December 11th. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Questions to the candidates
Pierre Habouzit [EMAIL PROTECTED] wrote: On Wed, Feb 28, 2007 at 04:55:58PM +0100, Raphael Hertzog wrote: Unfortunately we have big cultural differences when it comes to use of the money. Some people [...] feel they are some sort of second class developers because they will never have that opportunity to earn money while doing Debian stuff. Hey, that's not really a cultural difference here. If you really already know for sure some people won't never ever get paid, how could they feel otherwise? And I'm curious, which kind of developer will never get paid? For example, I'm a kind of developer who will never get paid: I have a day job that doesn't have anything to do with Debian, or even Linux or so. I am employed, not a freelancer. In the future, I won't even be able to read Debian mail at work. Therefore I will never be able to devote as much time to Debian as those who have the opportunity to integrate it into their work more or less. I don't feel bad about this, but it's a fact. And of course I will never be able to be paid by the project itself because of that, but that doesn't make me feel bad - neither about not being paid by the project nor about not being paid for computer work at all. So, personally I don't have any strong feelings against funding DDs, by whichever means. I have strong feelings, though, against dunc-tank and our current DPL's behavior in that field. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Questions to the candidates
Anthony Towns aj@azure.humbug.org.au wrote: On Sun, Feb 25, 2007 at 09:50:41AM +0100, Mike Hommey wrote: These questions may be skipped by AJ, because the answers are obvious. Hrm, I wonder if what's obvious matches what I actually think. What do you think of the dunc-tank initiative ? I think people should be able to help Debian in whatever way they think is a good idea, as long as they don't expect anyone else to help them. If everyone in Debian but you thinks you're crazy, you should be able to go outside Debian and prove them wrong, and Debian shouldn't have any problem with that. I don't understand how that relates to the question. dunc-tank was not really going outside Debian and prove them wrong, instead it was going half-outside and forcing a problematic decision, wasn't it? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Question to the candidates: inclusion of the kFreeBSD-* ports
Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Tue, Feb 27, 2007 at 07:05:02PM +0100, Jeroen van Wolffelaar wrote: On Tue, Feb 27, 2007 at 06:51:24PM +0100, Julien BLACHE wrote: If you're not doing that when answering questions during the campaign, how can I assume that you'll actually do when you'll be DPL ? The amount of questions asked during a typical DPL campaign period is nearly insane. I'd rather have a DPL that can prioritize and spend his time on what would benefit the project the most than one that'd try to do everything at the same time as good as it gets -- and running the risk of in the end not achieving much at all. Totally agreed. Also, I think it was both courteous and wise to try to respond promptly; if you let a question sit, in my experience, it becomes harder to answer. In particular if one wants to answer the rest of the mail at once. People start wondering why is he avoiding that part?. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: DPL 2007 (Resend)
Simon Richter [EMAIL PROTECTED] wrote: Hello, it appears as if my first mail was reflowed at some point, which made the signature go bad. It fails again here... -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: DPL 2007 (Resend)
Martin Zobel-Helas [EMAIL PROTECTED] wrote: Hi, On Sat Feb 24, 2007 at 11:21:38 +0100, Frank Küster wrote: Simon Richter [EMAIL PROTECTED] wrote: Hello, it appears as if my first mail was reflowed at some point, which made the signature go bad. It fails again here... it doesn't fail for me. Sorry for the noise. It seems my MUA's gpg configuration is messed up. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: BREAKING NEWS: Debian developers aren't trusted
Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Feb 15, 2007 at 08:37:27AM +0100, Martin Zobel-Helas wrote: On Thu Feb 15, 2007 at 13:13:36 +1000, Anthony Towns wrote: -vote dropped And readded apparently. Do we really have to have these conversations across multiple lists? i think someone running more than one autobuilder for more than _two_ years now (okay, not for the officical archive, but i see that as nonrelevant here) demonstrats very good that he mets your mentioned technical constraints. I didn't thought of Aurelien, but of a few other persons, who are acting as buildd maintainers for experimental and non-free packages. Experimental and non-free packages go to the official archive... I'm not seeing what you're asking for here. Are you so overworked, or are you deliberately forgetting? It has been suggested multiple times in the past to use existing or new hardware and add it to the set of standard autobuilders. Many arches do not meet the redundancy requirement, and we don't have autobuilders for i386 at all AFAIK. Moreover, the current buildd admin's apparently don't have adequate time to communicate, which could be ameliorated by adding people. Even if nobody had asked so far, we should ask people who seem capable of doing it. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: BREAKING NEWS: Debian developers aren't trusted
Anthony Towns aj@azure.humbug.org.au wrote: I've been thinking for a few days now that people in Debian disagree too much (hence the comments preceding my responses to Raphael in an earlier message), so starting now, I'm going to stop replying to mails by focussing on differences, and start with agreements. Let's see how long it takes until I can't stop myself from adding a but. Thank you for that mail. I'm not going to reply now, maybe later, for fear of not being able to be equally constructive. Or I'll just refer to it one day. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: BREAKING NEWS: Debian developers aren't trusted
Holger Levsen [EMAIL PROTECTED] wrote: Hi Marc, On Wednesday 14 February 2007 20:21, Marc Haber wrote: Judging from broad knowledge, you might send them to /dev/null for maximum effect. Do you really think constant senseless contentless ranting has _any_ (good) effect? It reminds us all that we still have something to do when etch is released: Start making some changes in the project. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: BREAKING NEWS: Debian developers aren't trusted
Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Feb 14, 2007 at 10:34:38PM +0100, Frank Küster wrote: Holger Levsen [EMAIL PROTECTED] wrote: On Wednesday 14 February 2007 20:21, Marc Haber wrote: Judging from broad knowledge, you might send them to /dev/null for maximum effect. Do you really think constant senseless contentless ranting has _any_ (good) effect? It reminds us all that we still have something to do when etch is released: Start making some changes in the project. Now now, is it really necessary to try to expel Marc for his comments? No, it isn't. My mail was meant serious. And the changes I have in mind are not to expel Marc ;-) Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: BREAKING NEWS: Debian developers aren't trusted
Martin Schulze [EMAIL PROTECTED] wrote: Hamish Moffatt wrote: ] I am really upset by the way the ARM build daemons are managed. The ] packages are not uploaded regularly, with sometimes three days between ] two uploads. [...] ] ] All of that resulted in ARM being the slowest architecture to build ] packages. [...] -- http://blog.aurel32.net/?p=33 I don't imagine Aurelien's any less upset, but as far as I can see, there aren't actual problems with the way arm's keeping up at present: Another problem is that the buildd email mailbox is apparently piped to /dev/null. FWIW, buildd mail is processed by a daemon, you are probably referring to something else. I guess he's referring to the [EMAIL PROTECTED] addresses. If these are only read by a daemon, that would explain a lot. And if you know this to be true, please write this to #342548 where I requested these contact addresses to be added to http://www.debian.org/intro/organization. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [GR] DD should be allowed to perform binary-only uploads
Kurt Roeckx [EMAIL PROTECTED] wrote: On Sat, Feb 10, 2007 at 03:27:25PM +0100, Frank Küster wrote: Steve Langasek [EMAIL PROTECTED] wrote: The error rate on requeue requests that reach me is significant, even from people who are well-informed and involved in the process (e.g., fellow release-team members). [...] I can name you the reasons why I don't have much of a clue about this (I think): - it wasn't part of the NM TS process, IIRC; all the technical details of testing propagation, freeze/unblock/, and general release team work were a bit meager maybe. In the NM process, you're not expected to learn about everything in Debian. It's about what you as a normal DD need to know. Exactly. Steve remarked that normal DDs (and even super-normal DDs) have no clue about this, and I think that what you need to know to pass TS is about what you can expect from normal DDs. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [GR] DD should be allowed to perform binary-only uploads
Steve Langasek [EMAIL PROTECTED] wrote: The error rate on requeue requests that reach me is significant, even from people who are well-informed and involved in the process (e.g., fellow release-team members). Maybe they're less cautious because they know I vet all requests, but I would expect that opening dep-waits/requeues up to the general dev population would result in a *lot* of unnecessary rebuild tries, stuck packages holding up transitions, etc., because the average developer simply isn't clued in on this stuff. Heck, before m68k was dropped as a factor in package propagation into testing, I was routinely finding bogus dep-waits set by the m68k buildd maintainers themselves, and that's only about a half-dozen people. I can name you the reasons why I don't have much of a clue about this (I think): - it wasn't part of the NM TS process, IIRC; all the technical details of testing propagation, freeze/unblock/, and general release team work were a bit meager maybe. - it's not easy to see what's going on there, and why. For example, I don't know where I can read what dep-wait means and why and how a package is put in this state. I think I know what it means and why it needs to be put there (manually), but that's just because it seems logical. And although I'm not the most involved developer, at least I once setup a buildd and read about wanna-build (about two years ago, forgot all...). - What's the contact point for asking for dep-wait or requeue? I guess it's that famous bunch of addresses that's also known for getting no response, and when you want to learn something, an occasional thanks, it seems you've grasped the principle or Thanks, but you missed the following is very helpful. Of course it's difficult to change that. Someone should write a nice page about it, and someone is, as usual, a synonym for not me. Aurélien got the first part of this back in December by keeping tabs on missing builds on arm and feeding this to James, but then he proceeded to set up a rogue autobuilder when he decided things weren't working to his satisfaction, so it's kinda hard to look at that and say yes, this is someone we should bring in to collaborate directly on w-b stuff for that arch. I won't express an opinion here on what Aurélien did, but maybe he is someone? (No, I have no idea what this has to do with -vote.) For my part, it's because a) I'm lazy, b) I'm currently not subscribed to -project or -devel (so please Cc me if you move). Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [GR] DD should be allowed to perform binary-only uploads
Andreas Barth [EMAIL PROTECTED] wrote: * Manoj Srivastava ([EMAIL PROTECTED]) [070210 04:44]: However, a buildd operator using qemu is not responsible for bugs filed on the packages created on his set up -- He is not performing an NMU. I disagree on this statement. If I e.g. upload an package to unstable linking to an experimental version of a library it is certainly my responsibility to fix it, independend whether I uploaded that package together with the source or not. ACK. Additionally, I got the feeling at times that the buildd admins do not take enough of responsibility with the packages they build: If something goes wrong, either because builds fail, or because packages don't work on some architectures, or (a combination) builds fail because always the same package on that arch doesn't behave well on their buildd, I think the buildd admins should feel responsible. And help debugging at least when asked. My experience with that is very bad. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [GR] DD should be allowed to perform binary-only uploads
Francesco P. Lovergine [EMAIL PROTECTED] wrote: On Fri, Feb 09, 2007 at 03:37:28PM +0100, Pierre Habouzit wrote: On Fri, Feb 09, 2007 at 02:44:37PM +0100, Francesco P. Lovergine wrote: The security implications of those practices should be evident to anyone. This is (sorry) bullshit. Binary only uploads are _not_ less secure than binary+source ones. Having a source side by side with the binary module does not give more security than binary-only uploads. Nice considerations, but I was talking about alternative/unofficial/untrastable/whatever-you-prefer buildd networks (which was at the origin of current vetos for some archs). So your considerations about binary vs source uploads can be interesting but not appropriate for the matter. I don't get the point. Where's the additional security problem with alternative/unofficial/untrastable/whatever-you-prefer buildd networks? I see a technical problem (reproducibility, in particular for stable-security builds) with binary uploads, but even there I don't see the difference between binary-only and bin+source uploads. I guess in the long run, we should establish i386 autobuilders and either only allow source-only uploads, or require bin+src, but discard the binary packages. On the social side, the availability of buildd admins for work and communication needs to be improved, by whatever measures are appropriate. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [GR] DD should be allowed to perform binary-only uploads
Sune Vuorela [EMAIL PROTECTED] wrote: On 2007-02-08, Bill Allombert [EMAIL PROTECTED] wrote: --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear Debian voters, I hereby propose the following General Resolution for sponsoring. --- The Debian project resolves that Debian developers allowed to perform combined source and binary packages uploads should be allowed to perform binary-only packages uploads for the same set of architectures. --- Why do you want to lose the ability to do src+bin uploads for arm+alpha? Or shouldn't there be a all release candidate archs somewhere in there? Huh? I read it as the exact opposite. If I'm not mistaken, any DD is currently allowed to do uploads containing binary packages of any arch if the condition is met that the upload also contains new source. In short: src+bin uploads are currently allowed. What this GR would change is that either - no one is allowed to do pure bin *and* src+bin uploads, only pure src uploads are allowed, or - pure bin uploads are allowed for any arch, or - there's a list of arches for which only pure src uploads are allowed. Alternatively, this can be interpreted as a GR for source-only uploads. Indeed. That should be made clear. Also, the wording seems unclear: Debian developers [...] should be allowed. Should normally means something: need not in all cases, but really should except if there are strong reasons against. Which seems to be just the current situation, from the point of view of those who have the power to reject binary uploads... Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Oct 26, 2006 at 12:18:33PM -0500, Manoj Srivastava wrote: On Thu, 26 Oct 2006 16:17:05 +0100, Ian Jackson [EMAIL PROTECTED] said: Perhaps it would be better if the policy maintainer were someone who was more willing to listen and take on board comments ? This sounds like a canard. What official Board comments have been disregarded by the current set of policy maintainers? Or do you mean Ian wants a Yes Man? Ian meant take comments under consideration, not listen to comments from the technical committee. Manoj sometimes gives the impression of not listening, because he doesn't nod and say yes, hm by e-mail. But if you assert that he is in fact not listening and not taking into consideration what he hears, you should back up this claim with some references. I have the opposite impression: The bugs that get no answer in the BTS are fixed soon, only those that he discusses might be tricky, or he reluctant to fix them. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Oct 26, 2006 at 10:34:01AM -0500, Manoj Srivastava wrote: On Thu, 26 Oct 2006 23:40:52 +1000, Anthony Towns aj@azure.humbug.org.au said: What has happened since is that the delegation has apparently been taken as a mandate for the policy editors to set policy according to their own opinion without any obligation to consult each other, or the developers as a whole. I'm not willing to have delegations exist in that way. Can you cite any instance that his has actually happened? Yes, you claimed that you didn't need any review because you were a delegate on IRC. I think that basing a decision with the DPL hat on just on what someone says on IRC is a bad idea. And of course you've been told multiple times that this didn't mean no public review, but instead no review through the normal review process. I'm not willing to let a delegation stand while if it's being used as a justification to not talk to other people; even if that's happening only hypothetically. You were acting in anger. You did not wait and talk with your delegate again the other day. I think a leader should not act in anger, but should take the time for talking. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
Anthony Towns aj@azure.humbug.org.au wrote: On Fri, Oct 27, 2006 at 08:17:17AM +0200, Frank K?ster wrote: Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Oct 26, 2006 at 12:18:33PM -0500, Manoj Srivastava wrote: On Thu, 26 Oct 2006 16:17:05 +0100, Ian Jackson [EMAIL PROTECTED] said: Perhaps it would be better if the policy maintainer were someone who was more willing to listen and take on board comments ? This sounds like a canard. What official Board comments have been disregarded by the current set of policy maintainers? Or do you mean Ian wants a Yes Man? Ian meant take comments under consideration, not listen to comments from the technical committee. Manoj sometimes gives the impression of not listening [...] Err, I mean Ian meant (take on board) (comments), and Manoj appears to have misinterpreted that as (take on) (Board comments). Nothing more. I'm not familiar with the expression take on board, but according to dict.leo.org you are still asserting that he does not take into consideration comments by others. I repeat what I wrote: , | But if you assert that he is in fact [...] not taking into | consideration what he hears, you should back up this claim with some | references. I have the opposite impression ` Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
Anthony Towns aj@azure.humbug.org.au wrote: On Fri, Oct 27, 2006 at 08:20:35AM +0200, Frank K?ster wrote: Yes, you claimed that you didn't need any review because you were a delegate on IRC. I think that basing a decision with the DPL hat on just on what someone says on IRC is a bad idea. IRC channels are used for official project business; the only difference between them and mailing lists is technical. I am not in IRC very frequently, but I have been there often enough to be convinced that this is very wrong. There's a big social difference between mailing lists and IRC. And both are different to meeting in person or talking on the phone. Should we found a group that collects money to pay the DPL's phone bill if he needs to give certain fellow DDs a call? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
Anthony Towns aj@azure.humbug.org.au wrote: On Fri, Oct 27, 2006 at 11:13:00AM +0200, Frank K?ster wrote: Anthony Towns aj@azure.humbug.org.au wrote: On Fri, Oct 27, 2006 at 08:17:17AM +0200, Frank K?ster wrote: Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Oct 26, 2006 at 12:18:33PM -0500, Manoj Srivastava wrote: On Thu, 26 Oct 2006 16:17:05 +0100, Ian Jackson [EMAIL PROTECTED] said: Perhaps it would be better if the policy maintainer were someone who was more willing to listen and take on board comments ? This sounds like a canard. What official Board comments have been disregarded by the current set of policy maintainers? Or do you mean Ian wants a Yes Man? Ian meant take comments under consideration, not listen to comments from the technical committee. Manoj sometimes gives the impression of not listening [...] Err, I mean Ian meant (take on board) (comments), and Manoj appears to have misinterpreted that as (take on) (Board comments). Nothing more. I'm not familiar with the expression take on board, but according to dict.leo.org you are still asserting that he does not take into consideration comments by others. I repeat what I wrote: I'm asserting nothing of the kind. Ian might be, but I'm not. Sorry, I was confused because you answered as if you could read Ian's mind, so I must have concluded you were the same person. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
Dear Anthony, dear all, Martin Wuertele [EMAIL PROTECTED] wrote: I disagree with the Policy delegation decision of our DPL [1] and therefore propose a resolution as defined in section 4.2.2 of the Debian constitution to delay the decision of the Debian Project Leader [...] Could we all please stop this? I feel that this slowly turns into a feud between nobody knows which groups and is eating up Debian and the fun to work on it. It is going to harm Debian, and also the current release process.. I have not seen an explanation by the DPL why he withdrew the policy delegation. But even if I had, I don't think it would change much. Anthony, I ask you as the DPL, please delay that decision yourself, thus making this stupid voting process unnecessary. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
Manoj Srivastava [EMAIL PROTECTED] wrote: On Sat, 7 Oct 2006 06:49:17 +0200, Sven Luther [EMAIL PROTECTED] said: 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. This clause is a violation of the DFSG, being able to modify whatever we ship (apart from license texts) is a core part of what free software is. Electing not to apply the DFSG violates the SC, which says everything we produce would be free according to the DFSG. No matter how you look at it, this proposal supersedes either the DFSG or the SC, or both, even though it does so only temporarily -- and superseding a foundation document requires a 3:1 super majority. I suggest eliminating this clause. Or voting for this clause with 3:1 majority. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
Kevin B. McCarty [EMAIL PROTECTED] wrote: I second the proposal below. It explicitly takes effect only for Etch, and it will allow installation on machines requiring tg3 net drivers (of which I have one). I believe this is the fourth second, so it only needs one more? Yes, me. I was confused earlier (I thought that seconding this proposal would delay the vote on the other ones). So here's my second: Sven Luther wrote: === START OF PROPOSAL === Definition: For the purpose of this resolution, the firmware mentioned below designates binary data included in some of the linux kernel drivers, usually as hex-encoded variables and whose purpose is to be loaded into a given piece of hardware, and be run outside the main memory space of the main processor(s). 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue, both upstream and in the debian packaging; however, it is not yet finally sorted out. 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will treat removal of problematic firmware as a best-effort process, and in no case add additional problematic material to the upstream released kernel tarball. 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. END OF PROPOSAL Yup. That one. -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) pgpl9FF0JEoj8.pgp Description: PGP signature
Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel
Ben Pfaff [EMAIL PROTECTED] wrote: Debian Project Secretary [EMAIL PROTECTED] writes: In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Do not enter a number smaller than 1 or larger than 2. You may skip numbers. You may rank options equally (as long as all choices X you make fall in the range 1= X = 3). These instructions are self-contradictory. Come on, don't you guys have nothing more interesting to do than bashing our secretary? Not? Okay, then please, as an entertaining exercise, find out where this text is from, how it comes that it is self-contradictory, and provide a fix for the script that does that. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel
Jurij Smakov [EMAIL PROTECTED] wrote: On Mon, Oct 09, 2006 at 04:33:42PM -0500, Manoj Srivastava wrote: On Mon, 09 Oct 2006 08:43:57 -0700, Ben Pfaff [EMAIL PROTECTED] said: Debian Project Secretary [EMAIL PROTECTED] writes: In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Do not enter a number smaller than 1 or larger than 2. You may skip numbers. You may rank options equally (as long as all choices X you make fall in the range 1= X = 3). These instructions are self-contradictory. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org Rubish. You have tow overlapping constraints. One constraint happens to be a superset of the other. There is not contradiction -- get your nit-picking right, fer gaeds sake. Whatever you call it, it's your screw-up. I don't even think there's anything seriously screwed. And if there were, the right thing to do would be to ask Manoj Please tell me where I can download the script you use, so that I can fix it, instead of blaming him. And yes, this is a concern, because there are plenty of people participating in this vote, who might be confused by this, but reluctant to ask for clarifications due to language and/or culture barrier. Anyone who ist not able to figure out themselves what this means might have a problem in their Debian work generally, since you can't expect that everything is spelled out and proofread when you're dealing with Debian packages. Anyone who has a language and/or culture barrier to asking if they don't understand something important, and/or at the same time is not able to find the information in the constitution that is the source for this paragraph, they will have a *severe* problem working in Debian. If it's so unbearably painful for you to hear the criticism, perhaps you should do a better job of proof-reading the ballot (and your replies :-) next time. Given the (often unwarranted) criticism Manoj had to face in the last couple of days, his reply wasn't really bad-tempered. And how about your offering him to proofread the ballot? Or just doing it, since he actually posted it in public for that very purpose? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Hi, first of all, I wonder why so few people from the teams involved take part in this discussion. I assume one reason might be that they prefer IRC. However, debian-vote is the list that's supposed to hold the important information for the vote, isn't it? Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Oct 05, 2006 at 10:08:40AM +0200, Sven Luther wrote: Indeed, so we need to strip those GPLed firmwares ? I'm not going to repeat myself on that again. No need to do that - I didn't read anything substantial from you yet. 5. We further note that some of these firmware do not have proper license, Again, no, Debian is not distributing anything we're not confident we have a valid license to distribute. And no, confident doesn't mean certain beyond all possible doubt -- it means we make a good faith attempt to comply with the stated wishes of the rights holders. The problem is that several people (also on -legal) have shown evidence that some of the firmware under discussion never was intended to comply with the GPL, for various reasons. I don't feel well with just ignoring this evidence. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Frans Pop [EMAIL PROTECTED] wrote: On Thursday 05 October 2006 11:43, Frank Küster wrote: first of all, I wonder why so few people from the teams involved take part in this discussion. I assume one reason might be that they prefer IRC. However, debian-vote is the list that's supposed to hold the important information for the vote, isn't it? No, it is because everybody who is remotely reasonable (with a few exceptions who are mostly forced to stay involved because of their roles in the project) has long since become totally disgusted with this anal discussion and the people pushing it . I can understand that. However, I'd rather have that discussion before the GR than after it, when it turns out that people do *not* agree about the meaning of it... And I know that Sven Luther is able to rise high emotions, but still it seems to me that what he says *is* reasonable. So, no, I will not support the current proposal (though I may vote for it). And, no, I am no longer interested in participating in the discussion, seeing as it is completely dominated by people I don't agree with anyway, who don't seem to be able to listen to arguments nor have any sense of what the majority of the project actually wants. I also have a feeling like Oh, well, nearly everybody wants the same, let's just do it without bothering about the wording. And I would be surprised if after the vote someone among the relevant teams would step up and say Hey, sorry to tell you, but these drivers (A, B, and C) cannot be kept in etch according to my understanding of the GR, and my investigation of their details. However, I do not think we can be sure, and since I do *not* want to be surprised, I'd rather have a proper discussion before the vote. IANAL, but at least I don't act like I am, like some others in this discussion who seem so unbelievably sure that _they_ are right and so, of course, nobody else can be. I have much more confidence in the more general consensus displayed by upstream and _all_ other distributions that firmware blobs *are* distributable under the GPL (of course, if there are individual drivers/firmware for which that is in doubt, this should be investigated, but I've lost any faith in the ability of people involved with debian-legal to provide an unbiased opinion on that). The problem is that there are individual drivers/firmware for which that is in doubt. For example, Larry Doolittle said recently: , | I am not perfect, but I have plenty of experience using and writing | firmware of many kinds. I would be very surprised if any of the | listed firmware is not derived from a human-legible design file of | one form or another. ` and even suspected that in some cases the firmware might just be sniffed. I am confident that this will have no legal consequences. But what if 2 days after the GR some kernel contributor steps up and says: Well, to be honest, I got this from a guy who owned the device and told me he had sniffed it? Will we exclude this firmware or have an other GR? The current discussion in no way helps the release of Etch. Why not *name* the drivers that get an exception? This way, anybody who *really* can contribute more than general doubt has to do it now, before the vote. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Asking for the ban of Frans Pop from debian-vote ...
Err, I didn't want to join this ugly subthread. But I do. Sven has earned quite some points in this list for trying to argue to the point. No matter whether he was wrong (nobody has really shown that?). Now his whining and the post to d-d-a has nearly emptied his account. However... Luk Claes [EMAIL PROTECTED] wrote: I don't believe he will try to attack you, though he might be cautious and you may be felt as attacked because of that... Err, how come you believe he will not attack, when the last mail that we have from him was an attack? Calling the ones who do take part in this discussion as being not among those who [are] remotely reasonable (with a few exceptions who are mostly forced to stay involved because of their roles in the project) is a personal attack on Sven (and maybe others), what else? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
Steve Langasek [EMAIL PROTECTED] wrote: The *relevant* claim I have made is that it is inappropriate to use our GR mechanism to attempt to *decide* whether GPLed drivers cause a distribution problem. The release team, the ftp team, and I suspect even most of the kernel team have no interest in a GR that authorizes any distribution of software which it at the same time asserts is illegal. Thank you for making this claim public on this list (where it belongs). I think it's an important point, and if you've already said this to Sven some time ago in a different medium, then I understand the reactions of some people towards him. I have previously given my own understanding of why it is not a problem for us to distribute GPLed firmware blobs pending license clarifications, but I don't see any indication that Sven is interested in understanding that POV, only in tilting at strawmen; so I don't intend to lose any more time on discussing this point beyond this single clarification email. It has already clarified much, and since I personally trust you, I don't insist on your repeating the explanation. However, I'd like to point out that other people are trying to follow this discussion, too. I don't think that your previous explanation was posted to -vote, which IMHO is the relevant list for such discussions. I feel it's particularly hard this time to follow the discussion; with no other GR have there been so many this has been said elsewhere (where? IRC?) statements by so many people, without trying to sum up on a web page or similar. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Sven Luther [EMAIL PROTECTED] wrote: List masters, this is evidence that Frans is not going to stop this, and as i asked yesterday, i now re-iterate the demand for his ban from debian-vote. Come on, calm down. That one was neither insulting nor attacking. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [PROPOSAL] Let's ship all firmwares included inthe pristine upstream kernel tarball in debian/etch.
Frank Küster [EMAIL PROTECTED] wrote: Hi, this is at least clearly worded, unambiguous, and if it succeeds will allow to release etch without delay (at least without delay because of firmware problems). It seems this is not true (qlogic), and still might be interpreted, namely as trying to force the teams and RM to include things they think are undistributable. Furthermore, I see Sven's current actions and statements as being destructive only, and do not want to help with that. Sven Luther [EMAIL PROTECTED] wrote: === START OF PROPOSAL === Given the difficulty of finding a common ground about the non-free firmware issue, the Debian Project does resolve that : 1) We allow inclusion in Debian Etch of all firmwares currently shipped in the upstream linux kernel tarball. === END OF PROPOSAL === I second this proposal. I don't care whether it's on separate or common, landscape or portrait, b/w or colored ballots. I therefore withdraw my second. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) pgpiV6YHCGUEe.pgp Description: PGP signature
Re: do not modify blobs
[EMAIL PROTECTED] wrote: Manoj - Has anyone done a survey to see how many do not modify blobs we are talking about here? Not counting files already removed in 2.6.17, drivers/net/appletalk/cops_ffdrv.h use-only (2) drivers/net/appletalk/cops_ltdrv.h use-only (2) drivers/net/tg3.credistr-only drivers/net/tokenring/3c359_microcode.h use-only (2) drivers/net/typhoon-firmware.h redistr-only drivers/scsi/qla2xxx/ql2100_fw.c redistr-only (1) drivers/scsi/qla2xxx/ql2200_fw.c redistr-only (1) drivers/scsi/qla2xxx/ql2300_fw.c redistr-only (1) drivers/scsi/qla2xxx/ql2322_fw.c redistr-only (1) drivers/scsi/qla2xxx/ql2400_fw.c redistr-only (1) drivers/usb/misc/emi26_fw.h redistr-only (2,3) (1) deprecated upstream, removed upstream as of 2.6.18? (2) marked for deletion by recent Kernel team position statement (3) redistributable as part of a Linux or other Open Source operating system kernel So, substracting the ones removed or scheduled for removal, this makes two that will remain? Or are the ones marked with (2) still needed for etch? tg3 is important (guessing from the fact that I was aware of its existence...), how about typhoon? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
Walter Landry [EMAIL PROTECTED] wrote: Sven Luther [EMAIL PROTECTED] wrote: So, the RMs are making claims that those sourceless GPLed drivers don't cause any kind of distribution problem, while i strongly believe that the GPL clause saying that all the distribution rights under the GPL are lost if you cannot abide by all points, including the requirement for sources. When Debian distributes kernel binaries, Debian makes use of clause 3a (accompany with source code), not 3b (written offer) or 3c (pass on written offer). So source has to accompany everything, even if no one is asking. Well, I think Sven didn't make the point of disagreement clear. It is whether what in the course of the GR's has been called sourceless firmware is in fact sourceless. If I understood Anthony Towns correctly, the ftpmasters and many others want to give those drives the benefit of doubt and assume that they aren't sourceless, but are, e.g., just dumps of unnamed registers and therefore the preferred form for modification. After all, they were what was given to the kernel people when the driver was released as .c and .h files under the GPL. So the real question is whether we want to do that, whether in the particular cases there's in fact any doubt, etc. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Hi, to me, and it seems other, too, Manoj's amendment seemed clear. However, Sven Luther has pointed out some points that could in fact be clearer, and has also suggested to take http://svn.debian.org/wsvn/kernel/people/jurij/firmware-position-statement.txt?op=filesc=1 into account. I'll try to suggest some changes in wording to Manoj's text that try to address these issues. This is not a formal amemdment. Rather, I'd like to openly discuss the text. The following is the full text of my Amendment , | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | 2. We acknowledge that there is a lot of progress in the kernel | firmware issue; however, it is not yet finally sorted out; | 3. We assure the community that there will be no regressions in | the progress made for freedom in the kernel distributed by | Debian relative to the Sarge release in Etch | 4. We give priority to the timely release of Etch over sorting every - | bit out; for this reason, we will treat removal of sourceless + | bit out; for this reason, we will treat removal of non-free | firmware as a best-effort process, and deliver firmware in udebs as | long as it is necessary for installation (like all udebs), and - | firmware included in the kernel itself as part of Debian Etch, - | as long as we are legally allowed to do so, and the firmware is - | distributed upstream under a license that complies with the DFSG. + | firmware included in the kernel itself as part of Debian Etch. + | We allow inclusion into etch even if the way we distribute the + | firmware leads to a violation of the license, if the current + | license does not allow modification, or if there is no source + | available. However, we still require that the firmware has a + | license that, in principle, allows distribution (possibly under + | conditions we currently cannot fully meet). ` What do you think? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Sven Luther [EMAIL PROTECTED] wrote: + | firmware included in the kernel itself as part of Debian Etch. + | We allow inclusion into etch even if the way we distribute the + | firmware leads to a violation of the license, if the current What do you mean by the way we distribute the firmware leads to a violation of the license ? This is a paraphrase of sourceless implicitly GPL-licenced drivers ? Why not say it directly then ? Yes, it was meant as that, but since I don't have a detailed overview of the firmware affected, I wanted to phrase it in a more general way. However, see my answer to Anthony Towns. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Anthony Towns aj@azure.humbug.org.au wrote: On Tue, Oct 03, 2006 at 02:09:50PM +0200, Frank K?ster wrote: + | We allow inclusion into etch even if the way we distribute the + | firmware leads to a violation of the license, Uh, no we won't. There are claims that the GPL, when applied to sourceless firmware, doesn't provide permission to redistribute because there's presumably a more preferred version of the source in existance somewhere. That's an *argument* that a violation may exist, not proof that one does. If that argument were accepted by Debian, we would not be distributing it no matter what GRs there might be, right up to the DFSG and Social Contract being entirely scrapped -- it would be *illegal* to distribute those works, both for us, for Red Hat, for kernel.org and just about everyone else. Okay. Since I never read anybody saying it this clearly (in other words, contradicting Sven when he asserted that the claims were true), I wasn't aware of that. It seems to me as if we might need to phrase the vote in a way that also makes clear which interpretation we follow. if the current + | license does not allow modification, or if there is no source + | available. However, we still require that the firmware has a + | license that, in principle, allows distribution (possibly under + | conditions we currently cannot fully meet). What do you think? That would make, e.g.: + | firmware included in the kernel itself as part of Debian Etch. + | We allow inclusion into etch even if the current license does + | not allow modification, or if there are hints that there exists + | a form more suited for modification than the binary form + | included in the kernel. However, we still require that the + | firmware has a license that allows distribution. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Manoj Srivastava [EMAIL PROTECTED] wrote: On Tue, 03 Oct 2006 14:09:50 +0200, Frank Küster [EMAIL PROTECTED] said: | 4. We give priority to the timely release of Etch over sorting every - | bit out; for this reason, we will treat removal of sourceless + | bit out; for this reason, we will treat removal of non-free This is a major concession. The proposal as it stands calls for exceptions for sourceless firmware, not any non-free firmware which we already have been pruning from the tree. Hm, according to http://svn.debian.org/wsvn/kernel/people/jurij/firmware-position-statement.txt?op=filesc=1 there are Binary blobs violating DFSG for other reasons, and these should get an exception for etch. At least this seems to be the opinion of many members of the kernel-, d-i- and release-Teams. One of the concerns I have seen voiced are about BLOBs distributed under the GPL, and some people have asserted that these are undistributable. This assertion is based on an unspoken assumption that the BLOB is not the preferred form of modification, hence the license is invalid, and thus can not be distributed. But it is, in fact, based on that assumption; but however compelling the arguments behind the assumption are, we don't know for sure. This proposal suggests we defer the investigation about the validity of the license until after etch has been released, since determining if our suspicions are true can be time consuming. Yes, thank you - this wasn't clear to me when I suggested the first version; Anthony has already pointed it out - see also my answer to him. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Summary? (Or: my vote is for sale!)
Manoj Srivastava [EMAIL PROTECTED] wrote: In that particular GR, the full text of the resolution was included in every ballot and CFV. If you were mislead, that means you did not even bother to read the mail you used to vote with -- sounds like the person doing the misleading was just you being lazy. In that particular case, the heading was still editorial changes, and given the public cries that the results (not the voting results) gave, he was not alone in that misconception. Therefore I don't think it's fair to call him lazy. If you've missed that there was a discussion what removing or adding the word software in a sentence means (a sentence that talks, as you perceive, about Free Software, anyway), it's just normal that you don't understand the implications. The consequences of those words may have come as a surprise to you (and indeed, they did to me as well), but there was nothing that I could have done about that. I don't think it's true. It has been pointed out that some of the consequences have already been raised during the discussion, but were overheard. And that's all Adrian and Marc were talking about. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Summary? (Or: my vote is for sale!)
Manoj Srivastava [EMAIL PROTECTED] wrote: But, if you think calling him lazy is unfair, but him implying I deceived him is fair, I amnot sure I can continue this conversation, I do not think he implied that *you* (the secretary) deceived him. He wrote that he believed in the text of the GR, but since the complete text of the GR was not drafted by you (I think the short title was, with an okay by the proposers?), I have no reason to believe he feels deceived by *you*. What seems to be clear is that people have little trust in being able to judge what a GR is about if they were not able to follow the discussion. And that's a problem we shouldn't ignore, or put aside by discussing whether anybody was deceived years ago, or called someone deceiver, or whatever. missed that there was a discussion what removing or adding the word software in a sentence means (a sentence that talks, as you perceive, about Free Software, anyway), it's just normal that you don't understand the implications. The heading was what the GR was discussed under for 5 months, and was on the draft ballot. How come no one corrected me and told me my heading was incorrect _then_, I have no idea; I just got my account when the editorial changes GR was put to vote, I think, and didn't take part since I didn't feel qualified. rahter than bitching after the fact and implying I misled people by choosing that heading? I guess people did that back then, but I didn't hear such things now. The consequences of those words may have come as a surprise to you (and indeed, they did to me as well), but there was nothing that I could have done about that. I don't think it's true. It has been pointed out that some of the consequences have already been raised during the discussion, but were overheard. And that's all Adrian and Marc were talking about. Chapter and verse, please. Which mailing list? Which post? Somebody asserted this week, probably on vote, that he'd already done that during the discussion. I missed the details, and frankly I don't care much. I think no one can deny that important facts and statements of opinion that *are* made in these huge threads, dispersed throughout the debian lists, will be missed by a significant proportion of DDs. Where was the issue of it ont being editorial raised that I overlooked when I set the title? Or you think implying that I discarded objections to the title without proof is fair, but me calling people who did not read the ballot is unfair? The very fact that the title was used throughout the discussion period, as you said, shows that it cannot be just you, or not at all you, who is to be blamed. manoj tired of being labeled as deceptive, misleading, or abusive of his postiion Maybe that's more in your ear that in people's (my, Marc's) mouth? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Manoj Srivastava [EMAIL PROTECTED] wrote: I've previously seconded another amendment, maybe too quickly, and then considered withdrawing the seconding because of the meeting during next weekend and the promised new proposal. For that other amendment, it doesn't matter anyway since it didn't get enough seconds. With this one, I'd be the fifth if I count right. I am going to second this, in order to speed up things, in case the minimum discussion period is counted from the last second needed. If something better (or more consensual) comes out of this meeting, I assume this proposal would be withdrawn, anyway. Therefore, I hereby second this amendment: , | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | 2. We acknowledge that there is a lot of progress in the kernel | firmware issue; however, it is not yet finally sorted out; | 3. We assure the community that there will be no regressions in | the progress made for freedom in the kernel distributed by | Debian relative to the Sarge release in Etch | 4. We give priority to the timely release of Etch over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware in udebs as | long as it is necessary for installation (like all udebs), and | firmware included in the kernel itself as part of Debian Etch, | as long as we are legally allowed to do so, and the firmware is | distributed upstream under a license that complies with the DFSG. ` Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) pgppuD19PhRZ0.pgp Description: PGP signature
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Sven Luther [EMAIL PROTECTED] wrote: On Wed, Sep 27, 2006 at 12:36:56PM -0500, Manoj Srivastava wrote: | 4. We give priority to the timely release of Etch over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware in udebs as | long as it is necessary for installation (like all udebs), and | firmware included in the kernel itself as part of Debian Etch, | as long as we are legally allowed to do so, and the firmware is | distributed upstream under a license that complies with the DFSG. ` Manoj, i want a clarification of what this actually means for : 1) firmware like the tg3 one, which is licenced under a 'permision to distribute under an hexa dump or equivalent format' but no further modification rights. This is clearly DFSG non-free, so tg3 has to go. Here, the upstream license seems to be non-free. 2) firmware under the GPL, but with missing source. The GPL is free, but the absence of source code for the firmware blobs makes it a violation of the GPL, and thus undistributable. Here, the upstream license is GPL, which complies with the DFSG, and the driver is therefore included if we are legally allowed to do so. The GPL *does* grant us the right to distribute binaries without source. It also requires us to do things we cannot factually do (namely, provide the source in the same place, or upon request with written offer etc.). But I understood the phrasing of Manojs proposal that it doesn't matter whether we can actually fulfill all requirements, as long as we can distribute. However, this interpretation of distributable is in contrast to the established interpretation for sourceless stuff in Debian. It would therefore mean to switch from distributable is where nobody can sue us with some hope to win to distributable where there's nobody who's going to sue us. I guess the wording of the amendment needs further clarification, in particular because IMO this switching should only be done for this particular case (and limited time), not generally. 3) firmware under a BSDish licence, but without source. The BSD is a free licence, but i question the freeness of binaries distributed under the BSD without source code. Of course, they are non-free. But there's no doubt that we are legally allowed to distribute them, and that they are distributed upstream under a license that complies with the DFSG. Hence they can be included if this proposal passes. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Call for votes
Manoj Srivastava [EMAIL PROTECTED] wrote: I am asking Frederik to accept this amendment, failing which, I am also seeking formal seconds for this. I would prefer that Frederik accept it, but in case he doesn't, I second this proposal: , | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | 2. We acknowledge that there is a lot of progress in the kernel | firmware issue; however, it is not yet finally sorted out; | 3. We give priority to the timely release of Etch over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware in udebs as | long as it is necessary for installation (like all udebs), and | firmware included in the kernel itself as part of Debian Etch, | as long as we are legally allowed to do so, and the formware is | distributed under a DFSG free license. ` without or, better, with the editorial changes ;-) suggested by Aníbal. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) pgpLbR628p8ye.pgp Description: PGP signature
Re: Splitting out Choice #1 from vote_004
Manoj Srivastava [EMAIL PROTECTED] wrote: How about: [ ] DFSG #2 applies to all programmatic works [ ] further discussion Followed by: [ ] Release Etch even with kernel freeware issues [ ] Special exception to DFSG#2 for firmware as long as required [needs 3:1] [ ] further discussion That looks fine to me. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Splitting out Choice #1 from vote_004
Josselin Mouette [EMAIL PROTECTED] wrote: I like the idea, but it eliminates some choices for the voter. With this setup, it is not possible to prioritize the firmware removal over the release, while still considering other options acceptable. How would I be able to express the following: [ 1 ] DFSG #2 applies to all programmatic works [ 3 ] Release Etch even with kernel freeware issues. [ 2 ] Special exception to DFSG#2 for firmware as long as required [needs 3:1] [ 4 ] further discussion with the separate ballot you are proposing? If the first option wins on your all-in-one ballot, we would still need a second vote to get an exception for etch. At least a minority does for sure want such an exception, therefore there will always be someone proposing GRs for the exception as long as there is no separate ballot. So better create a separate one in the first place Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: The Sourceless software in the kernel source GR
Martin Schulze [EMAIL PROTECTED] wrote: On Mon, 18 Sep 2006 18:46:50 -0700, Don Armstrong [EMAIL PROTECTED] said: But just like the groundwork and foundation of a structure, the non-actionable content of a resolutions can contain information on how the actionable content is to be interpreted. As such, it is part of the resolution, and needs to be included with the content made available to voters. Umh, then I need to ask why the resolution is not clear enough so that it does not need the preamble to know in which way the author has intended its interpretation? As Manoj pointed out already, courts look at the resolution when *interpreting* it, not at the preamble, so it seems pretty useles in that regard. As for german law, this is definitely wrong. Courts primarily look at the text, but the public documents produced in parliament during the creation process do in fact count when in doubt. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Proposal - Defer discussion about SC and firmware until after the Etch release
Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Sep 12, 2006 at 01:47:18AM +0200, Frans Pop wrote: There are also indications that a significant group of people within the project feels that the current Social Contract does not meet the best interests of the project in that the current wording is too restrictive and that a limited and conditional inclusion/support of some types of software should be possible. Example: support for loading sourceless firmware during installation. This paragraph seems to be speculation about the intent of other people; I think it would be better to either leave it out, or make it a statement about the voters' *own* views. Leaving it out is okay, but please don't phrase it in a way that implies that anybody who votes for this option declares to be discontent about the SC. I think I'd be willing to rank this proposal quite high on any ballot involving any of the proposals made so far. But I'd never rank a proposal higher than further discussion in which *I* declare that I want the SC to be reverted. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Firmware Social Contract: GR proposal
Sven Luther [EMAIL PROTECTED] wrote: On Tue, Sep 05, 2006 at 05:44:04PM +1000, Anthony Towns wrote: Obviously each of those polls only includes a self-selected minority of the people they try to cover, but the results seem fairly consistent both with each other, and what's been discussed so far on this list. Ok, this seems indeed obvious, from the discussion that followed, and the general consensus, but ... It therefore seems to me as though we're going to be failing to meet the social contract again, and as a consequence I think we should seriously reconsider whether the change we made in 2004 was the right one. So I'd like to propose the following course of action for consideration: ... you do a gigantic leap to this conclusion, which is not at all waranted by the above poll. The idea was that it is too short until the etch release (actually it is way too late, since kernel freeze was in early august) to solve the non-free firmware issue, and your little poll clearly stated that this was a poll aimed at releasing etch on time, not to revert the decision already taken on this subject. I agree. I have not taken part in the poll, mostly because I thought that the result was clear from the beginning, and my vote wouldn't change anything (it would have been exactly in the order that came out of the developer poll and which I anticipated). However, I always saw these questions in the context of releasing etch, nothing else. I do not in any way see this poll as an indication that we should revert the SC change, or that we have failed (in fact, we have succeeded to a large extent, just not 100%) or that we are being hypocritical. I also second the rest of Sven's statement ;-) Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Firmware Social Contract: GR proposal
Anthony Towns aj@azure.humbug.org.au wrote: On Tue, Sep 05, 2006 at 11:09:17AM +0200, Frank K?ster wrote: I do not in any way see this poll as an indication that we should revert the SC change, or that we have failed (in fact, we have succeeded to a large extent, just not 100%) or that we are being hypocritical. Consider comments like: [...] Or, more to the point, articles like Debian: too free? (28/4/2004; http://lwn.net/Articles/82536/) or Resolved: firmware is not software (23/8/2006; http://lwn.net/Articles/196641/). Personally, I find it absurd that we're acting in ways that mislead people into thinking that focussing on freedom is incompatible with producing a good system or delivering it on time. I do not understand how this is related to my statement. I haven't read the newer article word-by-word (and I don't know how a 2 years old article is interesting here), but it doesn't seem to me that it argues that freedom is incompatible with releasing a good system on time. Instead it nicely tells about different opinions and viewpoints, and a prediction like So Debian may well punt the issue again; expect its return in a year or two. is probably true, anyway, regardless of one's views on the relations between freedom, quality and timelines. It's exactly right to say we haven't failed -- we've made some huge successes since sarge, and we've got more to come. But by having a social contract that sets the bar higher than we can achieve, we keep having these successes viewed as failures, both by ourselves and our users. So instead of trying ot change the way some developers and users think, we'd rather change our foundation documents? In my opinion, a project like Debian is never ready, and never perfect. Everybody knows that we are not meeting the freedom goals in the SC to 100% (as well as other goals)[1]. But I do not see this as a failure, rather as a challenge. So why not try to explain this to the people, instead of lowering our standards? We don't lower our standards with respect to software quality or security support, either, even if we do miss our goals. Regards, Frank [1] and that is not only because of firmware, but also because there are still non-free bits hidden somewhere; they have been found in the past months and years, and they're probably going to be found in the future. -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Firmware Social Contract: GR proposal
Anthony Towns aj@azure.humbug.org.au wrote: On Tue, Sep 05, 2006 at 10:35:49AM +0200, Sven Luther wrote: It therefore seems to me as though we're going to be failing to meet the social contract again, and as a consequence I think we should seriously reconsider whether the change we made in 2004 was the right one. So I'd like to propose the following course of action for consideration: ... you do a gigantic leap to this conclusion, which is not at all waranted by the above poll. There's two steps: (1) we're not going to meet the social contract for etch (2) having repeatedly failed to meet the new social contract over an extended period, we should reconsider whether it was a good idea to adopt it in the first place Note that repeatedly means exactly twice, but only if you replace having failed by going to have failed. And extended period is about 2 and a half years, where 10 months of that time the project was in a state of paralysis because everybody was told we're going to freeze (something like) next week and release real soon afterwards. For me, the paralysis was prolonged by the no uploads with library soname changes soon afterwards, since working on non-free stuff in the old upstream version didn't make any sense - maybe this was similar for others. Therefore I think it is hardly fair to say repeatedly ... over an extended period. Maybe you talk like this because the fact hurts you so much; but honestly I think if we look at it from an objective point of view, we've achieved a lot, maybe more than could be expected. Only (1) is justified by the poll. (2)'s my opinion; I think it makes sense, but YMMV. Without (1), (2) is irrelevant, of course. Why should it be irrelevant without (1)? Would you feel less of a failure if we release etch in summer 2008, without non-free firmware in main? I'm sure you wouldn't; just the argument would be phrased differently (drop the repeatedly, replace meets by make a release that meets and extended by incredibly long). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Firmware Social Contract: GR proposal
Anthony Towns aj@azure.humbug.org.au wrote: There was a second ballot, which had six options on it, namely delay the SC change until Sept 1st 2004, delay the SC change until sarge releases, apologise, revert to SC 1.0, create a transition guide for the SC and DFSG, reaffirm the new SC. The last option failed to achieve even a simple majority (188 ranked it below further discussion, 155 ranked it above), each of the other options achieved a 2:1 supermajority, but only the delay the SC change options achieved the required 3:1 supermajority. Which pretty much argues for the position that the project wants the new SC, but is willing to compromise on the timeline of achieving it. Well, i believe that both of them basically said the same thing. Yes, we've had that discussion; the key point is you used the word software to cover more of the contents of main, than others did. The key point seems to be that you want to renew a discussion that, according to many's perception, has already taken place sufficiently, while you said somewhere that it hadn't... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Let's vote ...
Sven Luther [EMAIL PROTECTED] wrote: I thus propose that we held a vote ASAP, a real vote, not a poll, about what we are going to do about etch : 1) postpone the non-free firmware issue as proposed in this GR proposal. 2) delay etch until we finish discussing this issue and then implement the resulting course of action. [...] So, let's vote on this proposal, and then we can either continue to discuss this without having to deal with the etch release deadlines, or delay etch appropriately while we first discuss a solution and then implement it. Seconded ;-) -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
into such a position, especially when source code is clearly a desirable thing to have from our users and our perspective. -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) pgpHgm25o7zAm.pgp Description: PGP signature
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
Frank Küster [EMAIL PROTECTED] wrote: René van Bevern [EMAIL PROTECTED] wrote: Hello, I second this proposal independently of the presence of the D clause, although I prefer it being not removed. Same for me Ah, yes, and to make things clear: While I second this proposal, I still think that resolving the firmware issue can be delayed until etch+1, even if it hurts. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) pgp0rp5DqhIKN.pgp Description: PGP signature
Re: Constitutional Amendment GR: Handling assets for the project
Manoj Srivastava [EMAIL PROTECTED] wrote: On Mon, 24 Jul 2006 10:20:13 +0200, Bernhard R Link [EMAIL PROTECTED] said: * Manoj Srivastava [EMAIL PROTECTED] [060723 23:50]: So not giving the SPI board oversight on how Debian conducts it's internal affairs is sending an unfortunate message? Perhaps I do think we should send such a message; and indeed, we should consider the creation of a Debian Foundation, more sensitive to our eeds, with a constitution that precludes it interfering with our modus operandi or else it feels offended. Thanks for making clear the GR is not about some issue or topic but to drive some of your personal rants. I strongly uge you to actually read the discussion on the contents of the GR, and correct your gross misunderstanding of the issues involved before actually voting on this issue. Indeed - the discussion so far (and as far as I read it) does not back Bernhard's interpretation. There's been a sensible request to give one of the entities which this amendment talks about the opportunity to comment. I find your reaction to this very strange. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Constitutional Amendment GR: Handling assets for the project
Lars Wirzenius [EMAIL PROTECTED] wrote: to, 2006-07-20 kello 20:12 -0500, Manoj Srivastava kirjoitti: + 9.2. Authority +1. An organization holding assets for Debian has no authority + regarding Debian's technical or nontechnical decisions, except + that no decision by Debian with respect to any property held + by the organization shall require it to act outside its legal + authority. An exception is that Debian's constitution may + occasionally use SPI as a decision body of last resort. More importantly, the last sentence makes it sound that the Debian constitution requires the SPI to act illegally, whereas the exception really is to the fact that Debian doesn't have authority. I'm not sure how this is best fixed. I've got one other remark about this: This text is part of the constitution proper. Then why stay vague and write occasionally, instead of referring to the particular place where SPI is the last resort for decisions? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Vote analysis
Anthony Towns aj@azure.humbug.org.au wrote: If I remember how my script works well enough to use it correctly, the clone candidates (ones that a lot of voters rank next to each other) were: 326 votes (77%), Ari and Ted That's very unfair to Zeke. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Questions to the candidates
Steve McIntyre [EMAIL PROTECTED] wrote: 5. Do you see any services for our users or developers missing or poorly maintained? If so, which and what do you plan to do to fix this? I'm not directly aware of anything important missing at the moment. I know that we struggled to get packages.d.o running again, but that is now in hand. When we do have problems, more visibility on the causes and solutions would be useful - that's where we have had problems in the past. I'll turn the question around - what do _you_ think we're missing or not maintaining correctly? The services that I need are working OK, but I'm only one person. - Backups. This DPL debate has revealed that actually there are some meanwhile, but it's not yet properly documented, and some important services (alioth/svn) don't seem to have regular backups. - At some places, communication infrastructure is missing (e.g. buildd administration). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Questions to the candidates
Martin Schulze [EMAIL PROTECTED] wrote: Frank Küster wrote: 5. Do you see any services for our users or developers missing or poorly maintained? If so, which and what do you plan to do to fix this? I'm not directly aware of anything important missing at the moment. I know that we struggled to get packages.d.o running again, but that is now in hand. When we do have problems, more visibility on the causes and solutions would be useful - that's where we have had problems in the past. I'll turn the question around - what do _you_ think we're missing or not maintaining correctly? The services that I need are working OK, but I'm only one person. - Backups. This DPL debate has revealed that actually there are some meanwhile, but it's not yet properly documented, and some important Where do you want it to be documented? There has been an announcement on debian-devel-announce. At some place where it can be found even if you don't want to look up a month-old announcement. What about http://db.debian.org/machines.cgi, and the developers reference, in the section about Debian machines? There is technical project-internal documentation as well. Aha, where? There were backups of critical resources before, on my own harddisk, though... Other people made private backups, too. Good that this is centralized now. Many thanks for your efforts! Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Debian Backup Server (was: Questions to the candidates)
Moving this to -devel, it's off-topic for -vote; Cc to -admin. Martin Schulze [EMAIL PROTECTED] wrote: At some place where it can be found even if you don't want to look up a month-old announcement. What about http://db.debian.org/machines.cgi, and the developers reference, in the section about Debian machines? Umh... http://db.debian.org/machines.cgi?host=bartok already says Description: Backup Center of Debian I'd rather like to see information which services on a given machine is backed up there. Hmm, the developers reference is not my domain. Please send its maintainer a patch, file a bug report or drop its maintainer a line. I'll do that, once I've gathered enough information. There is technical project-internal documentation as well. Aha, where? It's not relevant for the end-user. /org/admin.debian.org/doc/backup.debian.org And in the da-backup package. Which doesn't seem to be available in sid currently? Anyway, before submitting patches I'd like to know some more things. I came to them because I considered which questions I had about backup services I used in the past, not because I think that I personally will have these concerns with Debian backup in the near future. - at which time of day is the backup made - for how long are the backups kept for a given service - what would valid reasons be for the DSA to extend the keep time for a given service? Or how do you decide about this time, anyway? - Would it, in principle, be possible to add home directories, or parts of them, if they provide services to the public? - What are the criteria for getting a backup rolled out - would I deleted that file that was not yet under version control be a request you'd happily process, or would that cause too much workload? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Question to all candidates about stable point releases
Anthony Towns aj@azure.humbug.org.au wrote: On Wed, Mar 08, 2006 at 08:14:21AM +0100, Marc Haber wrote: Uh, what the hell? You have four people asking basically the same question, and you wonder about this? Yes, because _all_ of them leap to the conclusion that I'm trying to delay something, when I'm not. I wouldn't say trying to delay, which implies deliberate action. But delaying seems to be correct from the information you gave, and not communicating, too. Where do you get this stuff? I've been reporting on what I've been doing in, afaik, more detail than anyone else in the project for the past few months. See, for instance: [... list snipped ] Public communication is important for people in key positions, but personal communication, especially when an answer has been requested explicitly, is even more. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
NM process (was: Question to all candidates about the NM process)
Bill Allombert [EMAIL PROTECTED] wrote: My own opinion is that if an applicant is doing a sizable job in Debian already, they should be exempted of much of TS. They have shown the skill to do the work they are more likely to do anyway, and they will have time to learn new skills as they need them. That might speed up the process a bit. (I don't know how you define sizable, but anyway:) I think the NM process is also something that the applicant can profit from a lot. When I became a DD, I had already been involved in teTeX packaging for quite a while, and there were some uploads that contained mainly changes made by me. I tried to make the packages both more policy-compliant and more user-friendly with respect to conf(iguration) file handling, I addressed licensing issues, etc. When you had asked me before the NM process, I'd probably have thought that I already knew most of the things important for handling teTeX. However, I did learn a lot both in the TS and PP (philosophy and procedures, or what's the name) part of the process, most importantly about library handling (which became important with the libkpathsea3-4 transition), evaluating licenses (which is important now, see the several bugs on the tetex-base source package) and internal structure of a binary package (knowledge which I seem to use every week). Not that I couldn't have learned that also later, when I really needed it. But the NM process was in fact a good opportunity to learn it right, get immediate feedback on my achievements (and not via the BTS...), and to take it serious. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: NM process
Pierre Habouzit [EMAIL PROTECTED] wrote: I agree with that. What is really painful in the NM queue, as I lived it, is the time between the steps [1]: [Received application] - [Application Manager Assigned] and between : [Appliaction Manager recommends to DAM] - Account Created. I took my NM that is quite recent as an example. It took me almost a YEAR (like in 11 monthes) to have my account: almost 3 monthes to have an AM 2 days to pass TS and PP 5 days more because of a mail of mine, stuck on an SMTP exactly 8 monthes (WTF !?!?!) to have then my account created. So what was wrong at the time when I passed [1]? Frank [1] https://nm.debian.org/nmstatus.php?email=frank%40kuesterei.ch -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Reflections about the questions for the candidates
Martin Michlmayr [EMAIL PROTECTED] wrote: However, what you say in your message (if people had asked for status reports they would've received them) is blatantly wrong. We did ask, and (usually) no good response was given. I also asked the DPL a question about backups of the development machines (after the CVS corruption last year) and never got any answer. At least one other person told me he had asked about the same, so this would have deserved a public answer. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Reflections about the questions for the candidates
Martin Michlmayr [EMAIL PROTECTED] wrote: * Frank Küster [EMAIL PROTECTED] [2006-03-05 18:48]: I also asked the DPL a question about backups of the development machines (after the CVS corruption last year) and never got any answer. FWIW, there is a dedicated backup server now. I don't know any details though (nor why it was never announced). So you also don't know what is backed up, and how often? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Reflections about the questions for the candidates
Martin Schulze [EMAIL PROTECTED] wrote: The missing announcement is totally my fault, so please don't blame any DPL for this. I don't think this is the point. If the DPL had cared about the problem and about transparency, he'd asked you how the service is running and why it hasn't been announced yet; or he had assigned one of the DPL team members to do that. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Question for all candidates
Bill Allombert [EMAIL PROTECTED] wrote: On Thu, Mar 02, 2006 at 02:49:37PM +0100, Mike Hommey wrote: Hi everyone, If you had to summarize your platform with 3 keywords, what would they be ? If such a necessity were forced upon me, I would answer Liberté Égalité Fraternité. Hm. So you mean we'd rather not reelect you, because in the second year that would be replaced by Liberté Égalité Guillotine? ;-) Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Question for all candidates about their Plattform pages
Jutta Wrage [EMAIL PROTECTED] wrote: 1. One of the candidates uses pictures to illustrate his platform, but does not give an alternative description for lynx users and blind people - accident? I didn't see any pictures in firefox, either. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Code of conduct, question to all candidates
Lars Wirzenius [EMAIL PROTECTED] wrote: What do you think of a code of conduct? What in your opinion would be a lower limit on acceptable behavior? Do you think that strict rules would be better than general guidelines? Who should be the judge if a particular case follows the code of conduct or not? Would the code be a good thing, or would it necessarily be a threat to freedom of speech, and stifle innovation? Should any kind of behavior be allowed on Debian mailing lists? And, do you think this code of conduct should be enforced? How? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: GFDL GR, vote please!
Anton Zinoviev [EMAIL PROTECTED] wrote: I think the following is an useful test. If the license forbids some modification that is necessary in order to adapt the document to some need, then the document is non-free. No, it is not, because according to many of your fellow DDs the result of applying this test to a GFDL'ed document is that it is non-free. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: DFSG4 and combined works
Yavor Doganov [EMAIL PROTECTED] wrote: On Thu, 09 Feb 2006 19:15:08 +0100, Frank Küster wrote: And then, has nobody ever raised the rumor that the purpose of this GFDL is non-free hullaboo is just to make sure that we will have our non-free section, for ever? I feel it the same way. The same as who? Surely not as me. I should have added some irony indicators. The fact that people expressed the opinion that Debian doesn't consider non-free software as antisocial and unethical scares me a lot. There are several reasons why people are for Free Software, and for sure not all of them imply that any non-free software is antisocial or, even more, unethical. I am glad that Debian does not fix itself to a specific ideologic motivation *why* we produce a Free operating system, but instead confines itself to an practical definition of what Free Software means. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: DFSG4 and combined works
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: What makes this entirely disgusting, is that the bees have extremely large overlap with the toads; the wasps with the frogs. I'm not sure about it, of course just because I'm a toad and a wasp. And then, has nobody ever raised the rumor that the purpose of this GFDL is non-free hullaboo is just to make sure that we will have our non-free section, for ever? I'm going to do something sensible now, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Democracy in Debian
Peter Samuelson [EMAIL PROTECTED] wrote: [Kalle Kivimaa] Actually, it is a direct procedure. The developers may, by way of a GR, override any decision of the DPL, including an appointment. [Lionel Elie Mamane] A vote run by the secretary obviously. Oh, how delicious. If you've got something to say, say it. I can't speak for Lionel, but... This _implication_ that the Secretary wouldn't properly run a vote concerning his own appointment is tiresome. I don't expect such problems with our current secretary. If that's what you meant, please say it directly. If not, what _did_ you mean? The procedure to replace the secretary is suboptimal, from a democracy point of view. And who do you think ought to run that vote? Well, e.g. the TC. I don't care enough about it to propose any changes, though. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Anton's amendment
Anton Zinoviev [EMAIL PROTECTED] wrote: On Mon, Feb 06, 2006 at 10:40:38AM -0800, Thomas Bushnell BSG wrote: Yavor Doganov [EMAIL PROTECTED] writes: This is not a proper example. Non-modifiability of secondary.c may obstruct further improvements of the program. This is not the case with the invariant sections, which do not prevent the manual to be enhanced. Sometimes an enhancement requires removing invariant sections. For example, if you want to turn the manual into a reference card. You can attach the invariant sections to the reference card and the conditions of GFDL will be satisfied. With the effect that the reference card is no longer a reference card (but maybe a couple of cards, or so). In other words: You can't turn the manual into a reference card. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Democracy in Debian (was: Anton's amendment)
Manoj Srivastava [EMAIL PROTECTED] wrote: Perhaps you'll never change your position because this is your reading of the DFSG. But for the sake of democracy you have to assume that people think different, so it is not fair to impose your view. Thankfully, Debian is not a democracy. We may vote on some issues, but that does not mean we are a democratically run organization. I'm not sure you are right, except if you don't call Debian a democracy because it's not a country (or town or the like) with a fixed group of inhabitants, but instead a volunteer organization. If we extend the term democracy to apply to organizations, too, or if we talk about democratically organized organizations, I'd say Debian is one. The powers of various offeces is spelled out in the constitution. As it is in most democracies. In this specific case, I am not going to let the spectre of democracy spur me into doing something I consider wrong. In a true democracy, I would either do what my constituency required even if I thought it wrong, or resign. I don't think this is true, especially since often you can't know what your constituency or its majority really thinks. Isn't it common that politicians stay in their function until their term ends, or until threatened or actually accused of an impeachment procedure, regardless of whether the surveys still give them a majority? In Debian, I am permitted to do what I think is right, in as unbiased a manner as I can, until I am removed from my post. And exactly the fact that your constituency can, by a spelled-out legal procedure, remove you from your post is a hallmark of democracy. In the case of the Project secretary, the procedure is indirect (by electing a project leader who will not reappoint you), but that's not a problem, and it's complicated by Debian's relation to SPI (it might additionally require electing members of the board of the SPI who agree with the leader in not reappointing the secretary). Except that non-DDs can be SPI members, the balance between existing secretary, leader and SPI board is an other characteristic of a democratic organization. If anyone wants to follow up on this, it's probably better to move to -project, but in that case please Cc me, I'm not subscribed there. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Anton's amendment
Anton Zinoviev [EMAIL PROTECTED] wrote: On Thu, Feb 02, 2006 at 07:58:44AM -0600, Manoj Srivastava wrote: It is a novel and unconventional reading of the foundation document. Possibly you didn't know how the free software community understands the words free software, if so I can see why you are considering this reading novel. This discussion used to be interesting, but now, err, excuse me. You are saying this to the person who has, according to the Debian constitution, the right and obligation to Adjudicate[...] any disputes about interpretation of the constitution. He's open to be convinced, but for sure not if you start telling him that he doesn't know his business at all. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Anton's amendment
Anton Zinoviev [EMAIL PROTECTED] wrote: On Thu, Feb 02, 2006 at 01:16:55PM +0100, Frank Kuster wrote: Anton Zinoviev [EMAIL PROTECTED] wrote: As it has been discussed here, having the Manifesto attached as invariant is not only non-free, but also quite problematic when you are trying to produce a derivative work that is either a) a compilation of many documents With the currently existing documents this is not a problem. Why? Because even if you want to create a compilation of all GFDL works ever released all over the world, the invariant sections that currently exist are very few. So the license is currently free in practice, because the option to thave invariant sections is only used by mainly one copyright owner who continues to add the same invariant sections over and over again? I am unable to see how you can make a conclusion like that provided you cited what I actualy wrote. I will repeat the dialog: Margarita: the invariant sections can be a problem for compilation works Anton: 1. Currently there is no such a problem. 2. Even if there is such a problem we already acknowledge as free some licenses that prohibit compilation works Roger: Why? Anton explains why 1. and 2. are true. I am not goint to repeat the explanations. In the words I cite(d), you tried to explain why 1. is true, you don't talk about 2 at all in the parts cited. And the reasoning why Currently there is no such problem is based on the assumption that there are only a few invariant sections (except for history, of course), in other words because mostly only the FSF uses this option. And I say: If a license could be regarded as free only because its flaws are irrelevant currently - because its non-free options are rarely used -, then it is in fact non-fre now. Do you really think that such a license is in fact free? What would happen if more people used it with the invariant sections option - at which point would it get non-free? Don't you see that such a reasoning can never lead to a general guideline about freeness, and must therefore be rejected? It is no less free than the licenses that directly prohibit compilation works. Personally, I would regard a license that prohibits compilation of a work under that license with other works under the same license, but from a different copyright holder, to be non-free. I am not aware of any works in Debian under such a license. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Anton's amendment
Anton Zinoviev [EMAIL PROTECTED] wrote: Only freedom 3 talks about distribution -- the freedom to improve the program and release your improvements to the public. Freedom 3 says nothing about your needs. What I wrote was the following: if your modifications solve some real need, not just your whims, then your modifications are usefull and freedom 3 gives you the right to distribute them. Removing lengthy political rants is clearly a real need if it comes to reducing space. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: A clarification for my interpretation of GFDL
Anton Zinoviev [EMAIL PROTECTED] wrote: On Thu, Feb 02, 2006 at 08:11:11AM -0600, Manoj Srivastava wrote: Firstly, if my needs require me to rtemove the secondary sections, and invariant sections, I should be allowed to do so Ok. However so far, nobody could give a resonable example of needs that can require you to remove the secodary sections. No, several people have. You just don't want to accept these, and therefore each time one example is mentioned, you start arguing about small details and only concede the others are right step by step, until nobody knows whether you have been proven wrong by the example or until nobody cares enough to further discuss your statements. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
