Re: [Debconf-discuss] [Debconf-discuss-discuss-discuss-and-keep-discussing] ...
On 12/04/2012 10:36 PM, Josselin Mouette wrote: Le mardi 04 décembre 2012 à 13:38 -0600, Gunnar Wolf a écrit : People, (most of) the Swiss team is pissed with the lack of trust and lack of respect we have been showing for months already, and that now some very vocal outsiders (i.e. Debian people who are not involved in this year's DebConf organization) are showing. Is the “outsiders” word also meaning to describe people who were asked for sponsorship and discovered later that the brochure they were sent had almost nothing to do with what’s actually going on? For a lot of people, your writing seems out of context. The sponsorship brochure is linked in: http://debconf13.debconf.org/helpus.xhtml If other people find that it *had almost nothing to do* with DebConf, please tell us. BTW: someone noticed me that I did a single-list-reply on my answer to your previous mail. Here my reply: http://lists.debconf.org/lurker/message/20121204.130912.539d5f32.en.html. Personally I see many of your *attacks* are not founded. Possibly DebConf13 is not a DebConf for you (anyway we have a fantastic Video Team), but we need such kind of DebConf every few years, which fits better other DDs. It seems that you are entering in the Linus mode. If people doesn't like next DebConf, it suffices to tell the world that you don't like it (and the reasons), not to construct artificial critics. And at the end the DebConf is done by DDs, so generic critics to DebConf will cause less bids for next DebConfs so less choice. We win the bid for only *one vote* (IIRC) and a lot of discussion, again *only one* other candidate. I fear that the discussion of last days could force to give up teams for next DebConf (which is IMO again /classic/ DebConf). What was the last non-govern-sponsored DebConf without financial troubles? DC7? So people: don't make a difficult job impossible *Help us: sponsoring DebConf13 and biding for DebConf in 2014 and 2015* ciao cate PS: Josselin: at the beginning of the mail I referred to you, but then it was more generic. Don't take it too personal. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50bef756.20...@debian.org
Re: How to Debian License
On 25.08.2010 13:41, Changwoo Ryu wrote: 2010/8/25 김기찬kkc.sk...@gmail.com: 한국어 ( Korean ) 안녕하세요. 한국에서 고등학교를 다니고 있는 학생입니다. 2009년에 Debian을 접하게 되었는데 Radhat 계열보다 쉬운 운용에 감탄하며 사용중이었습니다. 하지만 시중에는 Debian에 관한 책이 없어서 공부하는데 힘들었습니다. 그래서 제 후배들과 Debian을 공부하려는 리눅스유저를 위하여 책을 쓰려고 합니다. Debian Linux를 영리목적으로 사용하려면 라이센스를 구매해야합니까? Actually the Korean text is also confusing a bit. He said he was planning to write a Debian related book with his school friends. Then he asked whether he need to buy a license to use Debian for commercial (or proprietary, it is not clear in Korean language) purpose. Maybe he is asking whether he needs a license to write a Debian related book. Reading your translation, I would think that he is asking a license for trademarks, not for copyrights. So it would be more interesting to know the exact title of the book to see if Debian is used as attribute (e.g. sysadmin book for Debian systems) or as trademark (Korean Debian book). OTOH I don't know how to require license, but we definitely need some authority, or we will lose our trademark. ciao cate My answer: 말씀하시는 영리목적이라는 게 무슨 의미냐에 달려 있습니다. 예를 들어 단순히 데비안을 영리 기업에서 사용하거나, 데비안 CD를 돈 받고 팔거나 하는 일은 자유롭게 할 수 있습니다. 하지만 영리목적이라는 것이 데비안 CD를 구입하는 상대방의 자유로운 사용을 제한하는 라이선스를 적용하는 거라면, 못 합니다. 그러한 목적으로는 라이선스를 받는 방법이 없어요. 단지 데비안과 관련된 책을 써서 판매하는 걸 말하는 거라면, 그건 데비안의 소프트웨어 라이선스와 상관 없는 얘기입니다. 마음대로 하셔도 됩니다. 영어로 메일 쓸 때 번역기를 사용하지 마세요. 고등학교 수준의 영어가 한영 번역기보다 훨 낫습니다. (rough English translation for those who are curious) It depends on what your commercial purpose means. It is OK, for example, to use Debian in for-profit organizations, or to sell Debian CDs. But if you are thinking about restricting its distribution by applying your own proprietary licenses, you can't. There's no way to get license to do that. Or if you are talking about license of the Debian related book what you are planning to write, it is not related to Debian's software licenses. It's up to you. Do not use Korean-English machine translation when you write mail in English. Your high school level English is much better than today's machine translation results. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c7505e6.5030...@debian.org
Re: DEP-5 meta: New co-driver; current issues
On 12.08.2010 16:28, Bernd Zeimetz wrote: On 08/12/2010 03:27 PM, Lars Wirzenius wrote: On to, 2010-08-12 at 14:59 +0200, Bernd Zeimetz wrote: On 08/12/2010 02:45 PM, Lars Wirzenius wrote: It would be good to have DEP-5 done quite early in the squeeze+1 development cycle to give as much time as possible for adoption. A few comments: - Personally I find the format unnecessarily complicated and much more annoying to use than writing a normal debian/copyright file, especially for complicated cases. You're not required to use it. If you want to improve the format, please make concrete proposals, or at least explain why it is complicated and annoying. (If you've already done so, a URL will be sufficient. I do not, unfortunately, have the time to re-read three years worth of old discussions about this.) Its nothing that could be done by improving the format. Especially in large projects you often have a lot of weird situations reagrding the licensing, or GPL with various exceptions (not only to allow linking ssl, there are many more...) and a lot of other weirdness. For me its just faster to describe the situation in human-parsable words and copy+paste the license. For small sources or largish sources with one developer and one license it should not make a difference in the time one needs to spend to write debian/copyright. Don't understand me wrong, I'm all in favor for making debian/copyright machine-readable, I just think that there are more important things to do when you have to decide what to do with your spare time. But most of discussion is already taken, so now we have DEP-5 for free. And anyway not we are in frozen time, so I doubt that changes of copyright will be allowed before squeeze release. IMHO it is good to have some machine parseable format, so we can compare with other distributions, and probably do some cross-check with licensecheck and fossology (and probably we could generate a template from such tools). From few Debconf talks, it seems that corporate users want a better overview of licenses, so a DEP-5 will definitely help us, to gain again some more visibility. ciao cate PS: and transforming a machine parseable format to an other should be trivial (if the original format is well done). -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c640ada.2030...@debian.org
Re: DEP-5 and public domain
On 02.08.2010 23:27, Russ Allbery wrote: Very, very little software is actually truly public domain. US law, for instance, makes it essentially impossible to place something in the public domain via any mechanism other than dying and waiting 75 years (or whatever it is now). Not really. (just read few chapters of the book I won at DebConf). It states that after dying+70 year the work don't become public domain but copyright not enforceable). (I really don't get the difference, maybe is about authorship and derivative works). It is possible to put code in public domain, but it requires some legal papers (it is not enough to declare it in the file). base-passwd is a rare exception since it probably doesn't contain anything that's copyrightable (assuming you ignore the documentation, which is almost certainly not actually public domain). And even there, not copyrightable is not quite the same thing as public domain. I agree, the files (but the documentation) don't seems copyrightable, which is different as PD, so new keyword NO? ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c62b0ef.1040...@debian.org
Re: The role of debian-private
On Wed, Jun 09, 2010 at 03:46:13PM +, Clint Adams wrote: On Wed, Jun 09, 2010 at 04:52:42PM +0200, Giacomo A. Catenazzi wrote: I don't think traffic shoudl be keep at minimun, it is not a important list. We don't hide problem, so important things are send to d-d-a (which is the only required list for DD). Why would we not be better served if the people who think that there should be an exclusive club for patently idiotic discussions went off and made a separate, unofficial mailing list for that purpose? That way both groups could be happy. As wrote by Jonas, there is a risk of cabalization. Good discussion could also start from off-topic bad threads. Anyway I must explain the purposes or my previous mail: Enrico mail was (IMO) too restrictive, specially considering that it was the first mail on project. So I think it could be mis-interpreted. I replied to enrico's mail as a stand-alone. I know from IRC and few mails on -private that it seems that some most I left unread are funny (and highly off-topic). But this was not the subject of enrico mail. So I don't want that because of chatty mails we will set a too restrictive policy. [I'm pretty indifferent to the off-topic threads, as you see, I usually just ignore most of bad sub-threads, so restrict or not such mails are indifferent to me, but the very offtopic mails did seem the original topic of enrico mail] On 10.06.2010 12:37, Stefano Zacchiroli wrote: On Wed, Jun 09, 2010 at 04:52:42PM +0200, Giacomo A. Catenazzi wrote: Personally I like also that debian-private carries strong personal opinion (instead of public mailing list). I don't think I'm able to interpret the above properly. If that is to mean that on -private you don't need to be respectful of others (as we are supposed to be on other public mailing list), then I firmly disagree. I'm not saying that you said that, but I think the above sentence is a bit slippery in that respect. We know each others and we know how to interpret the messages That too is an argument that I personally don't like: we don't know each other any better on -private than we do on public lists. Keep in mind that lots of DDs have never met each other in person even if they share the status of being DDs. So, please avoid making the assumption that even if you write something in a bad/emotional way, it will be taken in a good way; be conservative in what you do, be liberal in what you accept from others applies pretty well to mails and can prevent tons of flames, on -private as anywhere else. The paragraph your quoted was also controversial to me. I don't like my arguments, but it seems that there are true. So I hope some other people will clarify this topic. My observations: Personal discussion (eyes-to-eyes) has so great values that list cannot even think to reach. For this reason BSPs, DebConfs and the famous keysigning+beer bilater meetings are so popular. You (Zack) are a great mediator, so you must confirm that: it is difficult to hide emotions, and some attack starts from miss-interpretation of people behaviour and people writing. People will learn about email conduct, but it take time (thus flames), and possibly one should live on the wrong side to learn about to write neutral mail and to assume good faith (no personal attack) by default on other intentions. It seems to me that new channels are gaining significance: irc and private email (especially on controversial topic). Why? I suppose (but I'm really not an expert, and not so involved in a lot of discussion, especially on last months) that being frank/open has a lot of advantage (and surely quicker) than a self-moderate public discussion. To conclude: On last DebConf there was a BOFH about the losing of debian-devel volume of mails. I fear that limiting (or better to enforce existing limits) on debian-private will not move discussion to other lists, but to private mail or simply to destroy communications. (IMO a lost) BTW an other comment about my previous mail topic: debian-private is not so private. Disclosing mail seems a good things for Debian: the violator usually (IIRC) must solve 10 or so bugs ;-) , so it is really not a place for highly secret things. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c10dafb.4040...@debian.org
Re: The role of debian-private
On 10.06.2010 16:16, Clint Adams wrote: On Thu, Jun 10, 2010 at 02:30:51PM +0200, Giacomo A. Catenazzi wrote: As wrote by Jonas, there is a risk of cabalization. Good discussion could also start from off-topic bad threads. I don't care if there's a cabal to discuss whether or not America, Hy-Brazil, Eurasia, and Scandinavia are continents or not. I don't care if there's a cabal who thinks that Maudite doesn't taste awful. I don't care if there's a cabal that thinks procreation is a good thing. None of these things need to be on -private. There are legitimate reasons to be subscribed to -private, and none of them require tolerating off-topic discussion. Good discussion would not seem to be irrelevant. If it's not meant to be secret, it shouldn't be there. I cannot imagine why this simple idea would be controvertible. ok, but again, it was not the point of this thread of debian-project. I agree with you (about some irrelevant messages), but I would like that some less important message can still be sent in debian-private, as we decided years ago (see below). There are two points about debian-private. - one about we don't hide problem and public discussion, so a lot of us care about feeling there is a cabal. and I think this was the point of enrico mail. - the second one is your point: few but more relevant messages. But we already had such discussion some (a lots) year ago. (I hope not disclosing too much informations, and anyway IIRC, thus I could be very wrong). The decision/compromise was to allow vacation messages, which are important for some people, but annoying for many other people, and surely not so important for the project (note: db has the vacation flag). But we aggreed to add the [VAC] string to such messages. So I interpret the decision as that few relevant message is not so important, especially if we can easily filter (with MUA/procmail) the (for us) irrelevant messages. So I think the procedure mark all thread as read with the few yearly hot-threads, it is an good compromise, instead of talking about new list, and *trying to enforce code of conducts (which AFAIK are not so welcome in Debian). If we agree about maintaining in debian-private VAC, health, children, exams, jobs changes, keysigning+beers, and similar in debian-private, I can fight with you against cultural/language/etc. flames of debian-private ;-) ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c10fe98.1010...@debian.org
Re: The role of debian-private
On 09.06.2010 16:08, Enrico Zini wrote: Hello, there is a discussion in debian-private about the role of debian-private. There is nothing private in that discussion, so I'm following it up here. So, some people are advocating in favour of a private mailing list for DD chatter. The fact that that idea is being very vocally pushed by no less than two people prompts me to double check some fundamental facts about the Debian project. So, here's how, so far, I understand things are supposed to work. We have a social contract: http://www.debian.org/social_contract where we say: We will not hide problems. This is generally taken to mean that as much as possible of Debian work and discussion ought to be public. That idea is violated, institutionally, in at least two points: - embargoed security issues, in order to be able to participate in vendor-sec; - and debian-private, which is supposed to host discussion about sensitive topics, with the understanding that private discussion should be kept to a minimum and moved to public lists as soon as it's possible to do so. My understanding is that the intention of the project is to keep these violations to as little as one possibly can, and this intention has also been reflected in the results of this GR: http://www.debian.org/vote/2005/vote_002 I used to take all of this as something obvious and well understood throughout the project. So, if someone thinks that those assumptions are wrong, I'd like to hear their reasons. Hmm. I think you are confusing secrecy with privacy. Embargoed issues should be keep secrets during some time, but anyway IIRC debian-security is not more automatically forwarded to debian-private, so I think it is not more a topic. But the most of the mail in debian-private are about privacy, not secrets so it is not IMHO a We will not hide problems. For privacy reasons we don't want to show all world about our vacation dates and destinations, about health and children, about personal issues we have with other people (in and outside Debian), etc. discussion keep to the minimum: no, we are happy to help, to congratulate, to exchange beer meetings, etc to our fellows. But still private issues, which IMHO it is not about hiding problems I don't think traffic shoudl be keep at minimun, it is not a important list. We don't hide problem, so important things are send to d-d-a (which is the only required list for DD). Personally I like also that debian-private carries strong personal opinion (instead of public mailing list). We know each others and we know how to interpret the messages (and IMHO the conclusion are inevitable pubblic, so also not hidding problems). There is less risk of forwarding a part of conversation which could give the wrong interpretation of personal opinion. With such arguments, I think we can understand better the meaning of debian-private and that there is not so important discussion in it. (Reading your mail, people could things that debian-private is an other (just joking) cabal mailing list. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c0faaba.10...@debian.org
Re: Using project resources for blends and non-free
On 11.01.2010 10:00, Marc 'HE' Brockschmidt wrote: This would mean adding a little load to buildd.d.o (which, looking at its current status, is negligible) and slightly increase the security risks as we now have more buildds connecting to this host. The latter should not be a problem, as buildds (id'ed by ssh keys) can only access a database through a wrapper, but I thought it should be mentioned. Considering that the additional load will be negligible, I think there is no problem to add few queues still debian-related. Ev. some queue priority and allowing to suspend queues will be useful (but I think these are already implemented): we don't want a openoffice backport during a transition. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian money
Steve McIntyre wrote: 1 New hardware / equipment a The DSA team have a wishlist of new hardware they'd like, along with a set of donated machines that need configuring and/or shipping. As far as I'm concerned, so long as the individual requests here look reasonable then they get approved as and when they happen. b Maintainers of big packages might benefit a lot if we can loan/donate big machines to them to make things faster. Should be an easy thing to work out - nominate such people please! Some months ago Debian asked for sponsored hardware: http://www.debian.org/News/2009/20090208 I did not read any news about his, so maybe we could use some money for such infrastructure hardware. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian money
Petter Reinholdtsen wrote: [Frans Pop] b Gnash. Petter is very keen on this, but I'm not so sure. Don't they have other ways to get funding? Thoughts? I don't think Debian as a project should sponsor upstream development. That's up to individual DDs. A working free software implementation of the flash web plugin is a requirement for Debian to provide a complete free software based desktop. At the moment flash is used on so many web sites that the common user will not accept a browser without working Flash. I believe that should be a priority of the Debian project to provide a complete free software desktop. And as Gnash is one of the few projects where money will help speed up development, I believe spending Debian money on Gnash is a good idea. Why should Debian not sponsor upstream development for projects that are important to Debian? It is useful not only for Debian, so IMHO Debian could donate some money, but only if other big distributions (RedHat, SuSe/Novel, Ubuntu, etc.) do the same. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Switching the default startup method
Martin Wuertele wrote: Hi Steve! * Steve Langasek vor...@debian.org [2009-08-24 10:03]: The main thing I know about file-rc is that it's a corner case that further breaks upgrade handling when packages need to renumber their symlinks in /etc/rc?.d. I know embedded is often used as a catch-all to describe all kinds of crackful ideas, but I'm at a loss to see how this makes file-rc in particular appealing to anyone. It's easy to maintain, it doesn't require a bunch of symlinks like sysv-rc nor does it require the magic of insserv, it is easy to change the order in which services are started without time-consuming resolving dependencies (eg linksys WRT54GS v1.1, asus wl500g boot pretty fast with it). BTW the resolving dependencies is done at installation/update time, not at every boot. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
Patrick Schoenfeld wrote: Hi, On Mon, Aug 03, 2009 at 06:40:06PM +0200, Sandro Tosi wrote: THEY STEAL our packages Uarg. That sentence let me discard everything sensible/intelligent you might have said in your mail. I often read sentences like that in the discussion. It makes me sick and wonder if I do invest my time in the right project. Lets face it: If you do make things open source you /must/ and really /should/ accept that others do re-use it according to the license under which you license it. Ubuntu does exactly that. If we start telling that Ubuntu people are thiefs because they re-use our work to make derivative works from it, then we should be consequent and call ourselves thiefs too, because we steal the work of our upstreams. But OTOH it would be just better and easier to not forget what Debian stands for. Free Software. Everytime you might feel its appropriate to tell Ubuntu (or other downstreams) thiefs, it might be worth to hold in a moment and have a look at our Social Contract which you accepted, when you became part of Debian. Yes, but OTOH we strongly support copyleft softwares versus the BSD- like softwares, because we expect to have back the works and because we expect to behave as a big community. I agree with you, it is not thiefs, but anyway the feeling are not so good, especially because we are talking about a big player with enough resources to behave as we do with upstreams. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Freezing times: [Re: Bits from the release team and request for discussion]
Luk Claes wrote: time-based freezes == For the squeeze release (and future releases), we are considering a time-based freeze, meaning that the freeze will happen at a predictable and predetermined time with the release happening at a later time once the release requirements are met. We think that having a time-based freeze would enhance the responsibility among developers to plan ahead and make sure that the version they want to get in the next release is one that is stable and can be well supported. time-based freezes would make a release schedule more predictable as long as we make sure that what gets into the freeze is sensible. We do think that a time-based *release* is a no-go for Debian though, as we only want to release when we are ready in order to not compromise the quality of the release. About freeze timing we think that DebConf should definitely not fall into a freeze and that we should leave time after DebConf to integrate the possibly disruptive changes we introduced by doing cool stuff at DebConf. We noticed that releases in the first quarter of the year worked out quite well in the past like both Etch and Lenny. Taking these into consideration we think it would be best to freeze in December. As freezing in December would mean that a release cycle always takes about the same amount of years, let's consider the various options. Having a release cycle of 1 year would be very short and would cause some issues with security support and upgrades. Having a release cycle of 3 years would be quite long and would mean a very long security support. So it looks like a release cycle of about 2 years seems the best way to go forward. To have the better synergies with Ubuntu and upstreams, I think we should freeze at the same times as Ubuntu, so in March or/and September: - upstreams will deliver the high quality software at these times December is to early. - common BSPs could increment size of fixer, so on long term also the number of developers in Debian and in Ubuntu. - we could really profit from ubuntu: more testing Ubuntu has more users, but Debian has more bug solvers, so IMHO we need to wait for Ubuntu freeze, to have more tester (thus more solved bugs) . I find not to good to solve bugs on an already obsolete release (KDE or gnome), so that nearly only our user will profit about this. I think in this manner, on long term we really help Ubuntu, but also for sure Debian and the Debian quality. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DAM and NEW queues processing
Bernd Zeimetz wrote: Mike Hommey wrote: On Thu, Jun 25, 2009 at 01:32:14AM +0200, Bernd Zeimetz wrote: Don Armstrong wrote: On Wed, 24 Jun 2009, Steve Langasek wrote: Ok - then I guess my problem is that the list of names included in these is so non-notable (and is empty most weeks anyway...) that it doesn't register at all with me. Would it be enough to just have a special automated mail congratulating new developers on -newmaint (or modify the subject of this mail to congratulate them?) I'd be happy to modify the cronjob to send such mails to -project, if the interest is large enough. Does anybody want to come up with a proper wording? I'd say it would nice to have a mail to -project with a welcome for new maintainers, a thanks for retiring maintainers, and the new number of developpers. But that might be much harder to setup. Neither FD nor DAM have anything to do with retiring maintainers. They're removed from the keyring and the account is disabled. Ahh... the old dear bureaucracy! It is not my task, so go away and never come back ;-) Is it so difficult that a cronjob will call two scripts and merge the results in a single mail? So let start with FD/DAM mail and let other to improve later with new relevant informations. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DAM and NEW queues processing
Lucas Nussbaum wrote: On 23/06/09 at 12:55 +0200, Bernd Zeimetz wrote: Lucas Nussbaum wrote: On 23/06/09 at 12:06 +0200, Bernd Zeimetz wrote: No way. Most reports show that a lot of NMs don't know about a lot of things asked during the NM process. This is true even for those who are DM already. Is that really problem? We need people who take the right decisions (and that includes asking questions when they don't know or are not sure about something), not people who can repeat all our documentation from memory. 80% or more of the questions are questions about daily tasks, so yes, you're supposed to know that from brain. Or you should at least have heard something about it, which is another things the NM process is for: educate people. The fact that NM is about educating people is a problem: NM should be about checking that it's OK to grant the DD status to an already-educated applicant. That way, the process would be much shorter, it would be easier to find people willing to help with it (AM, FD, DAM), and applicants wouldn't see it as something so useless and boring. Ev. we could set up some infrastructure, to let other DD to do some jobs. As sponsoree I look much more about packages than procedures, but if we (sponsoree) have some infrastructure, we can check some extra tasks (and maybe with a note, just to increment quality of attempts). I think this will not require much more time. So at the end the FD will control what was checked by other DDs (and with few checks to confirm that DDs did a good job) and doing the rest of checks. This will surely increment quality of sponsored package, but probably remove some work of AM, FD, DAM. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DAM and NEW queues processing
Bernd Zeimetz wrote: Charles Plessy wrote: Le Tue, Jun 23, 2009 at 11:30:53AM +0200, Lucas Nussbaum a écrit : - the NEW queue could also be based on peer-review: one could ask one or two another DDs to certify that the package is OK (licensing-wise) to be uploaded to unstable. Then ftpmasters would just be responsible for verifying that enough DDs have reviewed the package. And ftpmasters could still choose some interesting packages and check them manually. Dear all, I have documented a simple procedure for doing so, that I am experimenting. http://wiki.debian.org/CopyrightReview Witout a proof that peer-review works, it will be difficult to change the current system, so I encourage you to join the experiment. Your concept fails - usually the problematic issues are not even mentioned in debian/copyright. And if somebody is able to download packages from the NEW queue Debian is distributing them. If this is not allowed, you could end up with some extra fun with lawyers... We could make public only the sources (a lot less problem on linkage and derivate works), and make clear that are only temporary license preview. We can set up an authentication (only from DD), which is also good to give feedbacks. We could also monitor that there is no abuse e.g. 90% of download come with a feedback in next days. Anyway: sources was already public (I don't think DDs are so crazy), thus we are not the primary target, and IANAL, but it is not a distribution. I don't see differences on ftpmasters and DDs on downloading sources to check license. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft vote on constitutional issues
Thomas Bushnell BSG wrote: On Wed, 2009-05-13 at 10:53 +0200, Giacomo A. Catenazzi wrote: DFSG is a guideline and a target: we must no go far as the nearest point we reached, but it still a guideline. Consider: - we never had a full DFSG Debian (also when DFSG was written) - we have RC also on stable releases. What should we do in such cases? Block all dDbian website, all mirrors, etc. because it is clearly against our foundations? No. The Social Contract does not leave vague how we use the DFSG. It could say that we take the DFSG as a guideline, or as a target, but it does not. We provide the guidelines that we use to determine (...) DFSG is that guideline. Guideline indicates direction. (note that it is in the sentence, not as acronym) We promise (...) will be free. *will* indicate a future intention. we must not add more non-free software (but by errors), and we should try to remove non-free (the target). It does not say that we try to abide by it, or that we weigh it against other things; it says that we *do* abide by it, 100%. I wonder, how could it be written even more strongly? So, I think the actual social contract is not so strong. Debian releases only distributions that contain only softwares, documentations and art-works that is free according to DFSG would be stronger. But it is very dangerous to have to strict rules: if we found a non-free software (outside the exceptions) in potato o in lenny, do we annihilate because we don't follow the guidelines? As you wrote, there will always bugs, and also wrong attributed code, unchecked licenses, ...; so I would not like to have a stronger statement. I have the feeling that if it said we will never intentionally include non-free software in Debian, no matter what the circumstances you would still start telling us that this is a mere statement of goals and intentions, but not anything actually binding. Of *course* there will be bugs. We cannot promise not to make mistakes. The argument is *not* about whether non-free things get in unintentionally. We can't make a promise never to make a mistake. But we can promise not to intentionally include non-free software, and it is this promise which we have now broken twice. We I joined debian, I read that we (DD) was never obliged to do things (but with a kind request to retire gracefully if we cannot improve debian). But I don't find anymore such document. I cannot work on Debian kernel: I've no time and capabilities, so I cannot help reducing such non-free code, but I'm helping in other parts. So what we should do? Never release, because we have no man-power on some complex tasks? But so we throw the other works, where we removed non-free software, and improved freedom. I try to do most as I can do, to have a 100% free Debian, on my packages, and on other packages, but you are telling me that I go to every RC bug and try harder to resolve bugs? [I can do it, but I'm sure it is a waste of time] ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft vote on constitutional issues
Thomas Bushnell BSG wrote: On Tue, 2009-05-12 at 17:06 +0200, Wouter Verhelst wrote: I think this is the core of the disagreement. I do not call it a temporary override of a foundation document; I call it a temporary practical consensus between the needs of our users and the needs of the free software community. I don't understand. Either Social Contract section one and the DFSG prohibit the distribution of a non-free blob in the release, or they do not. If they prohibit it, then it is an override to distribute notwithstanding the prohibition. If they do not prohibit it, then no resolution is necessary. You seem to say an inconsistent thing: that they do prohibit it, and we can avoid that prohibition by calling it a practical consensus instead of an override. Surely, however, it is the effect that matters, and not the label you give it. DFSG is a guideline and a target: we must no go far as the nearest point we reached, but it still a guideline. Consider: - we never had a full DFSG Debian (also when DFSG was written) - we have RC also on stable releases. What should we do in such cases? Block all dDbian website, all mirrors, etc. because it is clearly against our foundations? No. Where to put the line? This is the main problem: we have different interpretations and our foundation documents (and related discussions) doesn't provide us a true (and clear) interpretation. So I applaud the recent discussion to rewrite (better, clearer) our foundation documents. ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian Membership
Matthew Johnson wrote: My goals with changing the membership procedures are: - To turn NM into a more evolutionary process where some privileges and rights are granted earlier in the process and the qualifications for the later parts are based mainly on the work done with the reduced privileges - To make some of those reduced privileges legitimate goals for people to aspire to in their own right - To acknowledge more types of contribution - To retain at least some of the oversight and checks of the current NM process for all of the technical parts of the membership process - To decouple of technical and political positions in the membership Being part of the project, particularly with upload rights, is something I believe _should_ be difficult. This restriction on access to the archive is one of our strengths, it gives us a higher quality of packaging (yes, there are exceptions, but they should be the exception, not the rule) than would otherwise be possible. I'm confused about your intents, reading last quoted paragraph with the To turn NM into a more evolutionary process. I totally agree that the upload right should be difficult to gain. But the frequent discussions about NEW queue give us a lot of informations: - we want easier upload right (e.g. for NEW packages) - we suck on upload quality (only on NEW queue ???) - we must be anal/fundamentalist on license checks (not only on NEW queue). Thus: - we (DD) must improve = I would like some QA on existing DDs on new proposal - how can we trust to DMs, if they don't have technical review and license review? The last point seems to contradict common interpretation of to turn NM into a more evolutionary process. In conclusion: - a agree with more type of contributors, and more fine grained access control (translators, bug checkers and patcher, QA, infrastructure ...) - vote only on makers (uploader, translator, ...) (who makes something in last years). - upload should be difficult - quality control on existing members (to force not to be to lazy) ciao cate -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Joerg Jaspert wrote: Hi, I have felt for some time that the low requirement for seconds on General Resolutions is something that should be fixed. We are over 1000 Developers, if you can't find more than 5 people supporting your idea, its most probably not worth it taking time of everyone. this will mean that future GRs would need 30 other people to support your idea. While that does seem a lot (6times more than now), considering that a GR affects more than 1000 official Developers and uncounted amounts of other people doing work for Debian, I think its not too much. Especially as point b only requires 15 people, 3 times the amount than now, in case there is a disagreement with the DPL, TC or a Delegate. I agree that actual quote is to low, but I don't think things will change with an higher quote. FYI in Switzerland: for a GR resolution we need 100 000 subscribers, i.e. 2% of potential voters (4.3% of actual voters), and it is more difficult that seconding a Debian GR. Anyway, since 2000 it was called more than 30 times [1] (and all but twice the GR was rejected). For this reason, I think an higher quote probably will not reduce the number of GRs. ciao cate [1] not counting a lot more referendums and mandatory votes (i.e. government driven amendment to constitution), and not counting cantonal and local votes. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: More frequent dinstall runs and mirror pushes
Joerg Jaspert wrote: Hi as the subject says, we are planning to increase the frequency of dinstall[1] runs. Our current plan is to have 4 runs a day, switching From the current [07|19]:52 schedule to the new [01|07|13|19]:52 schedule. All times are in UTC. For the mirror network, this means two more pushes a day, but from current experience this is manageable. If we ever go to more than four runs our mirror network needs a different setup, as current rsync deficiencies[2] do not easily allow more frequent pushes. I plan to switch to the new schedule in 2 weeks. But so it will add new Packages.diff/ files ? I propose to do this after lenny release, when we will have more packages in the queue, and possibly a new way to handle the Packages.diff/. I don't think that such diffs are designed for a lot of updates. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian's job is not to help people who think the world is unfair
Jurij Smakov wrote: On Wed, Nov 26, 2008 at 06:17:45PM +0100, martin f krafft wrote: also sprach Gunnar Wolf [EMAIL PROTECTED] [2008.11.26.1807 +0100]: And no, it's not Debian's flaw or problem - but Wolfgang's complaint is IMHO very well in place. It will reach the clueless HR recruiter, and -as he posted to -jobs- probably other HR people pondering on writing to Debian. This is precisely my problem, it comes across as a statement from Debian, when in fact it is the voice of a few people (who seem to have little idea about HR and running a business). This is why I replied on -jobs, because Debian does *not* have any policy preventing or allowing job offers with age restrictions. You are correct, we don't have such a policy in place. However, one of our foundation documents (which I'm reasonably proud of) claims that we will not accept any software with license which discriminates against any person or group of persons into the distribution. Yes, it's a stretch, because we can be fairly sure that people (as opposed to firmware :-) are not software, and they don't have a license. I, however, have a difficulty understanding the mindset of people who can, at the same time, stand behind these principles, and be comfortable with what looks to me as a clear-cut example of unfair age discrimination (thanks to Ben for suggesting the correct wording). I see our foundation document (which I'm also reasonably proud of) with completely contrary view. We cannot accept licenses that: - forbid usage for hostile (war) purposes - forbid software to unfair governments. (IIRC these two was the standard explanation of that point in DFSG) so we explicitly allow unfair use of our software. Our mailing list are different? We should not support SELinux (or discuss with NSA people) because it was created by NSA? PS: For the job position I've two comment: - google ask people to leave home for 3 months (learning in silicon valley). This is discrimination of fathers or mothers? - Usually the age limit is not an hard limit, but it means: you could learn a lot, we don't require lot of experience, but we will pay you at lower scale. I think other non-discriminatory formulation should be prefered, but ... we are technical people, not fluent English writer. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Wouter Verhelst wrote: On Fri, Oct 24, 2008 at 04:30:31PM +0200, Giacomo A. Catenazzi wrote: Joey Schulze wrote: Giacomo A. Catenazzi wrote: To cite an extreme example, Ingo Juergensman doesn't do packaging nor anything of the above. Nevertheless, he's an active member of the Debian community for many years (even despite severe problems) by supporting the m68k port with hosts and maintenance. He should be able to vote on general Debian issues such as the project leader. This is an interesting point. Do you thing Ingo Juergensman could not pass a simple test on packaging or on BTS? He could anyway ask ftp-master to have upload right removed. Why should he do a packaging test? Why should translators of the website? They do not intend to do packaging. It should be not mandatory, but I think it is interesting to him to know the very basic packaging. Regardless, at the time, Ingo felt that there was no way for him to be able to get through NM without knowing stuff about packaging. That is not a good thing (I've known Ingo for quite some time now, and he's a very knowledgeable person, on Debian as a whole and the m68k port specifically) Ok, So a modified proposal: - no DME: we should trust our voters. - A recommendation to the people/teams responsible to choose the test structure and to validate candidates: The tests should be on various tasks/areas, Some areas are possibly mandatory (ID check, social contract, BTS, legal) Note: ev. targeted tests on BTS and legal (e.g. about copying, trivial changes, etc, instead of software compliance, but remember the most of last votes was about licenses and non-free) Some area are targeted: packing, using i18n system, vcs and web scripts (for web-translators, etc.), basic security (for shell accounts). Who pass the mandatory test and is a developer i.e. an active contributor to Debian could became DD and thus voter. Based on the targeted tests (but free to have also other ways), the ftp-masters, i18n-team, web-team, debian-admin, could grant permissions for uploads, ssh, etc. In this manner we have no formal differences between DD, but restricted access based about capabilities. Changing permission is thus done in less formal way by various teams. In short: Debian cares about active contributors which agree on social contract etc. and who help Debian to advances. The ftp-masters care about packages (NEW packages, NEW uploades), etc. Note: so in this proposal there is only one formal change: the debian contributors. The other things could be done informally. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bureaucracy (Re: Developer Status)
Manoj Srivastava wrote: On Thu, Oct 23 2008, Giacomo A. Catenazzi wrote: Joerg nominated teams, not persons. My and the people involved should be read as and the number of teams involved. I don't think nominated is the correct term here. Joerg did not nominate the secretary for anything, as far as I can tell. ;-) You are right. First meaning of nominate: To mention or specify by name. In this case was roles not names. Thus I would better s/nominated/listed/. (I'm lucky to speak a Latin derived language: most of times my guesses are still correct, but maybe archaic) The number of teams increment the bureaucracy (changing the proposal, coordination), and doesn't fit the Debian structure (role [proposers] vs. hierarchical [proposal]). Huh? The people Joerg talked to were people who would be affected by the proposal. For example, the secretary was called in to comment since this proposal would require changes in the coting pmechnism, and I was invited to give feedback on how big a change that would be. Also, he watned to ask about the constitutionality of the proposal. I don't see how this solicitation of early feedback in any way adds to the bureaucratic angle. Could you write it in a simpler manner. I think I understand your use of solicitation, but Wikipedia writes (first sentence): In the United States, solicitation is a crime. I don't think you mean that crime. Not the plain solicitation, but the need to solicitate so many people. All these people are affected by the proposal, and I was predicting how these people will handle the proposal? how they will interact each other? How many policies will have from every groups? (e.g. names/loginname, expirations, checks,...) How to pass new contributor between teams? Who will care that applications are not forgot in some internal (thus bureaucratic) step? (Remember the problem with NM waiting account) We had problem with busy key people, this proposal will give further burden to such the key people. So probably they will nominate (delegate) powers to new people, possibly with new role (helper, assistant), with rules and bureaucracy. We will have problems with some people, so how to deal with such problem? The roles listed by Joerg need to agree how to handle such cases (sign, i.e. bureaucracy), hoping they are not to much busy or temporary MIA. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Joerg Jaspert wrote: Developer Status I start loving more this proposal. Debian is about developing a free operating system, but there's more in an operating system than just software and packages. If we want translators, documentation writers, artists, free software advocates, et al. to get endorsed by the project and feel proud for it, we need some way to acknowledge that. This is where our proposal comes in. Debian is mainly software and package, so a full (voting) member should have some knowledge to our package system. I have some fear about free software advocates. We use we are technical people to downgrade flames. In facts we are technical people. I want more technology and less politics in Debian. Let other organizations to do the most advocating and political discussion. I don't want that we do task of EFF, and I don't hope that OSI will not do distributions. Nobody forbid us to be member of other organizations. I think this is a major point to improve Debian: let give Debian a small and more definite scope, and let do the other works in upstream and/or activists organization. Second point. I don't like changes only to acknowledge other people. Personally I trust some Debian contributors not because they are DD, but because they are visible contributors (in facts time to time I see that some of them was not DD). We want these changes to acknowledge some contributors, or to speed up they contributions of such people? I think that with such proposal we will not increase contributors, but a better working structure for these people. A new user can start out in two ways depending on their personal preference. The first is the non-technical way: Debian Contributor -- A DC is someone that has a strong relation with Debian through the work they are doing for/around Debian. Possible examples are translators and documentation writers. DC have to pass the ID check, agree to the Social Contract/DFSG and have successfully answered a set of questions[DCDMQ] similar to the ones used in the current first PP step.[TEMPL] I think this is the step one for all contributors: having a know key would simplify also sponsoring and mentoring (which is the first step also for DM). Instead of a set of questions, I prefer some advocates to relevant people (e.g. from i18n expert, from sponsoree, from team,...) The second way is the technical one: Debian Maintainer - They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. In contrast to current DM this is based on source packages and allows uploads of new binary components, which have to pass NEW, too. I agree in general, but I think the power should be defined by ftp-master (type of uploads, NEW uploads, delayed queue, ...). The NMC will give a packager license and eventually further checks at request of ftp-master for other packagers. After the 6 months time in Debian Contributor/Maintainer are passed, applicants can apply to get Debian Developer status. There are now 2 different classes of DD status available, one with and one without upload rights. To not add confusion we selected to name them Debian member (no upload rights) and Debian Developer (upload rights). Both are project members, i.e. with voting and all other constitutional rights, the term classes does not indicate any kind of first or second level membership. Debian Member - A DME is someone that previously had DC or DM for at least 6 months but additionally want to have voting rights or needs a login on a debian.org machine for their work. A DME can nominate themself as DPL, can be delegated rights from the DPL and can start any GR, basically do everything our foundation documents allow project members to do. DME are not able to freely upload any package, but DME can have the same upload rights a DM can have, ie. own packages, if they follow(ed) the DM rules for this. Following our Constitution §8.1.2, DAM declares that Debian Members are to be treated as Developers who do not maintain packages wherever the term Developer is used in one of our documents. I think we don't need DME. I requires a minimum of packaging skills (with debhelper it could be very easy, and IMO bugs handling skills are necessary). We can do simplified tests: at this level we trust that a person which is not comfortable with programming will not do complex uploads. Why do we want to forbid a trusted person to do trivial uploads, binNMU and helping other DD (e.g. without temporary a working key) to upload packages? I thyink that voting people must be trusted and responsible, so no need to distinguish. We could expel the DD which do frequently completely wrongs uploads. contributor.debian.org mail --- We are considering to implement
Re: Developer Status
Joey Schulze wrote: Giacomo A. Catenazzi wrote: Joerg Jaspert wrote: Developer Status I start loving more this proposal. Debian is about developing a free operating system, but there's more in an operating system than just software and packages. If we want translators, documentation writers, artists, free software advocates, et al. to get endorsed by the project and feel proud for it, we need some way to acknowledge that. This is where our proposal comes in. Debian is mainly software and package, so a full (voting) member should have some knowledge to our package system. Documentation, Translation, User support, Events and stuff have nothing to do with packaging. Debian community members mainly being active in these areas should be granted voting privileges as well. They wouldn't need package upload privileges, though. To cite an extreme example, Ingo Juergensman doesn't do packaging nor anything of the above. Nevertheless, he's an active member of the Debian community for many years (even despite severe problems) by supporting the m68k port with hosts and maintenance. He should be able to vote on general Debian issues such as the project leader. This is an interesting point. Do you thing Ingo Juergensman could not pass a simple test on packaging or on BTS? He could anyway ask ftp-master to have upload right removed. I think most of our experienced users will have enough capabilities for a simple test, and anyway, I would not put him in an other category. Let giving him other tests, but let him to be a normal Debian Developer. who is not interested on upload packages. No need for new categories. Voting people should be trusting people, so without constitutional limits. He would decide to have restricted rights. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Joey Schulze wrote: Giacomo A. Catenazzi wrote: To cite an extreme example, Ingo Juergensman doesn't do packaging nor anything of the above. Nevertheless, he's an active member of the Debian community for many years (even despite severe problems) by supporting the m68k port with hosts and maintenance. He should be able to vote on general Debian issues such as the project leader. This is an interesting point. Do you thing Ingo Juergensman could not pass a simple test on packaging or on BTS? He could anyway ask ftp-master to have upload right removed. Why should he do a packaging test? Why should translators of the website? They do not intend to do packaging. It should be not mandatory, but I think it is interesting to him to know the very basic packaging. Managing web site translation I think it means also using some scripts, so very basic of debhelper and packaging is not so complicated. I'm DD and I passed the following tests (in 2000 or 2001): ID, philosophy of Debian, legal (license check), packaging, handling bts, basic English, etc. The tests was supposed to see if the person know various aspects of Debian, not only to see if he can pack. Do you think a Debian voter would not be interested on other areas? Not to be an expert, but a very simple tests could be useful, and not the test for usual packers. Eventually we can make it DD without test, and up to ftp-master to see if upload rights should be granted. We should trust our voters! Without distinction of uploaders and others. In future maybe he could do simple language packing or NMU upload of new translations. Let decide the NM about what kind of test would be necessary for various interest. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Joerg Jaspert wrote: Developer Status This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. Reading the proposal and the people involved, I think the proposal is to complex and bureaucratic and it doesn't fit to the Debian structure. As example of Debian structure, how to you will answer to: Why do you have the power to do this? I hope you don't answer with I've the supercow power, but you will answer with roles. So why don't move the proposal with roles instead of the naerly concentric power structure? So I propose: - Debian contributor as in your proposal (ID check, agree to the social contract, ..) and then we define roles: - Esperanto debconf translator - Chinese website uploader/maintainer - uploader/maintainer to package X - uploader/maintainer of package of team Y - testing security (IIRC the search also for non DD members) - DPL - etc. Every team or team master choose who as power and what kind of power. DD would become a label of people with debian constitutional rights (vote etc) and some standard powers, and I think we could eventually restrict the rights (i.e. to have a non packager DD, or for a sabbatical DD) ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Manoj Srivastava wrote: On Thu, Oct 23 2008, Giacomo A. Catenazzi wrote: Reading the proposal and the people involved, I think the proposal is to complex and bureaucratic and it doesn't fit to the Debian structure. If you are not looking at the proposal on its merits, but you are basing your decisions o the person(s) involved in its creation, then you are falling into a logical fallacy called argumentum ad hominem. Logical fallacies detract from the merits of your counter proposals, unfortunately. It is only bad English. Joerg nominated teams, not persons. My and the people involved should be read as and the number of teams involved. The number of teams increment the bureaucracy (changing the proposal, coordination), and doesn't fit the Debian structure (role [proposers] vs. hierarchical [proposal]). It is bureaucratic also because of the number of stages between user and DD, etc. Anyway, it seems that other DD have similar ideas, so I let other to express them. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian and non-free
Manoj Srivastava wrote: I think that dilutes the message that those packages are non-free, and reduces pressure on the authors to release the documentation under a free license. main non-free programs documents firmware art-work games I prefer a division by reasons (but it would be a lot more complex, so probably not feasible): non-free: firmware hardware/software dilemma not-enough-free trademarks, patents, non-commercial, legal concerns, etc. e.g. GFDL, various non-free compression programs standards and RFC. This is more a political decision historical/emulators i.e. old binaries/BIOS, which could maybe seen as orphan works. Some fans could try to free the code free-alternative-not-yet-available the worse category free-alternative-available - as netscape and areader, they should be removed when good alternative are available. - as for flash: waiting for other project to mature (which is soon expected) artwork compatibility - e.g. commercial fonts. -I think JDK is in this category: available good alternative, but some people need it for compatibility. - Maybe also some keys, certificates Anyway, reading the list of non-free software, I think we could remove some of the package, e.g. - album: there are a lot of free alternatives - agrep: why not packing the old version? - autodir: we need a free alternative! - axe: is it obsolete? (last upload in 2006) - crossvc: obolete? ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FSF not considering Debian as Free (Re: Debian and non-free)
Filipus Klutiero wrote: I could help to set-up the infrastructure and providing the non-free.org domain, but I don't think I have enough infrastructure to handle the machines. I'm afraid you'd be wasting your time. I don't think the problem is the domain name hosting non-free. Richard Stallman wrote: ;-) I've no problem for wasting few time and few money. Thus, the debian.org site and the software in it should not refer to the existence of non-free.org in such a way as to suggest getting non-free software from there. I tried for years to convince Debian to do this, but I did not succeed. Translated to the current way things are done, this means that according to Richard, the Debian website or Debian refer to the existence of the non-free component in a way that suggests getting non-free software from there. I'm very curious what part of the website or Debian would be doing this for years, but I guess someone could ask Richard. IMHO, if we create the non-free.org, it should help Debian to better manage the different queues and policies. Endorsement of FSF is good, but not so important. Anyway: - I prefer the freedom to choice the software (anyway free software is better) - without non-free software (non-free printer driver), do you think RMS would have created FSF, GNU and GPL? So I want non-free.org as a method to push writing/improving free alternatives (or forcing protocol designed to open protocols, but this is more difficult). ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confusion about non-free (Re: Bits from the Debian Eee PC team, summer 2008)
Russ Allbery wrote: Giacomo Catenazzi [EMAIL PROTECTED] writes: Russ Allbery wrote: I recommend not attributing such judgements to the configuration files of software packages. Sorry??? It is more that a configuration file, and BTW the same notation it is also used by apt. Archive and its format are an area of ftp-master. I disagree. The Release file in the archive is a configuration file that is part of the software interface to the archive. The terminology that it uses refers to capabilities within the archive maintenance software and within the software that downloads files from a Debian archive. It does not have anything to do with legal, administrative, or focus decisions taken by the Debian project. Mixing the terminology used for a software package with the terminology used for the founding organizational documents of the project is a mistake, in my opinion. The Debian archive software is general software that could be used for any project, even with an entirely different use of the component feature that has nothing to do with licensing. We happen to use it for licensing and to separate things that are part of the distribution from things that are not, but this is not in any way inherent to the component concept within the archive software. ok, you are right, and BTW the Release file of Ubuntu seems to interpret the parts in a different manner. OTOH: - people tend to use more the dak terminology (also because it is exported on apt pinning) To be correct, it should also be noted that some terms are not 1 to 1 with policy: i.e. dak uses updates/main (i.e. in security archive) as component. Policy area has only the main part (which is called segment when used with segment/section). - policy is also not consistent on terminology (but finally it was noticed and you corrected: thanks Russ!) - using two notations, for two different field, is confusing So I think we should setup a BOFH in DebConf, with policy, dak, ftp-masters, apt, etc. people, to check the terminology (and identify the subtle differences, e.g. component vs. area), and to write a Debian glossary, which possibly reduce confusion (which started this thread). There are interested people for such BOFH? The bug is only relevant to policy, but as stated by policy team, debian/copyright, interpretation of DFSG, archive sections (devel, libs, mail), etc. are areas outside policy, but they are in ftp-master hands. So IMHO what Debian means (linked to DFSG) and what Lenny means (archive) is outside debian-policy (and outside of the cited bug). This is unfortunate. I don't agree that this is the case to the extent that you describe, or that it follows from that bug or from other Policy discussions, although I agree that thet Constitution and Social Contract have more to say about this than Policy does. I was proposing an explanation of the origin of confusing and inconsistent terms. Probably there are better explaination. [but if I don't write a plausible, probably wrong, explanation, nobody will write the right explanation ;-) ] ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confusion about non-free (Re: Bits from the Debian Eee PC team, summer 2008)
Robert Millan wrote: [ adding debian-project ] On Sun, Aug 03, 2008 at 01:53:54PM +0200, Robert Millan wrote: On Sun, Aug 03, 2008 at 08:28:19AM -0300, Ben Armstrong wrote: Earliest Eee models fully supported in Lenny Lenny will release with the atl2 ethernet driver and the non-free madwifi-source now works with the earliest Eee models as well, Hi Ben Lenny is Debian. non-free is not part of Debian. Check the Social Contract. I wonder what is it that we do wrong to spread this confusion so much that it affects even Debian developers themselves. What is this to blame? Would it be the FTP archive layout? Perhaps having an unified BTS? There are some problem with terms/words: they are inconsistent, sometime also along the same documentation file. BTW I'm trying to document it: http://wiki.debian.org/PolicyGlossary Anyway: From policy: The main category forms the Debian GNU/Linux distribution. But I'm not sure that Lenny is only Debian: From http://ftp.de.debian.org/debian/dists/lenny/Release (thus using 'dak' terminology): : Origin: Debian : Label: Debian : Suite: testing : Codename: lenny : Date: Mon, 04 Aug 2008 08:39:59 UTC : Architectures: alpha amd64 arm armel hppa i386 ia64 mips mipsel powerpc s390 sparc : Components: main contrib non-free : Description: Debian x.y Testing distribution - Not Released So lenny is made from main (Debian), contrib and non-free. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making Debian work: a question of trust indeed
MJ Ray wrote: martin f krafft [EMAIL PROTECTED] wrote: Sam's mail was to James, CC the project. Don't you think that it's a little immature and definitely very premature to discuss the matter before James sent his own reply? Yep. Hopefully a reply will come. I also hope there was an attempt at private communication before that open letter, but there was no indication of it. Reading the mail of Sam give the impression that that was not really attempt to contact him with email or IRC, But reading carefully: : This is certainly no longer something : about which I can afford to wait 2 months between each answer : from you. I think Sam contacted several time elmo about the issue. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Screw non-free.
Adrian Bunk wrote: On Thu, Mar 18, 2004 at 12:28:59PM +, Colin Watson wrote: I've started occasionally building powerpc non-free packages with a private sbuild installation (I should set up buildd too, but haven't got round to it). It's relatively slow work since I need to check the copyright files first, though. ... Are there any packages in non-free that don't allow rebuilding? I think in principle yes. I.e.: - non rebuildable binaries packages (binary only packages) - packages with license that don't allow you to redistribute modified binary (pine and mozilla are nearly at this level) - packages that don't allow you to modify sources, and with actual buggy sources (not buildable with out libs, with 64-bit archs, with non popular archs, ..) Technically only point 2 are not really rebuildable, but you should check the other two cases, or you will loose time and resources. ciao cate
Re: IMPORTANT/URGENT - PLEASE REMOVE MY NAME FROM YOUR SITE!
Hmm According zurich police web site (from memory), mails written in this form: - subject with IMPORTANT/URGENT, capitalized - capitalized body - name of some not yet well developed country - ... should be taken as nigerian spam, thus deleted immediatly or ev. reported to police :-) Anyway, the mail in question is listen in hundred or more archieves, in a lots more mailboxes, so delection on your site have only a little advantage to you and big trouble to other people. BTW you made the error, in writing a mail and sending to non trusted sources. Also for this case, I recomend you to read the web site of zurich police or the site of the (swiss) federal department of justice. You will learn about spam and some thing you should not do on the net. Remember the old (usenet?) tip: DON'T email or post anything you're not willing to see on the evening news, on your company bulletin board, in tomorrow's newspaper, or on your resume. giacomo, (not so ingenouos researcher, Zurich) [EMAIL PROTECTED] wrote: I WAS VERY SURPRISED TO FIND MY NAME SHOWN IN YOUR WEBPAGE UNDER THE FOLLOWING LINK: http://lists.debian.org/debian-user-spanish/2003/debian-user-spanish-200301/msg00400.html I DO NOT BELIEVE THAT YOU HAVE A RIGHT TO PRODUCE NAMES ON YOUR WEBPAGE WITHOUT INFORMING THE PEOPLE CONCERNED. FURTHER, AS THERE WAS A SCANDAL WITH THE PETITION AGAINST WAR (SIGNATURES WERE STOLEN FROM ANOTHER PETITION ON AFGANISTAN AND UNO HAD NEVER BEEN INVOLVED IN THE SIGNATURE COLLECTION), I DO NOT WANT TO SEE MY NAME APPEAR IN ANY WEBSITES REGARDING THIS ISSUE. I AM ALSO SURPRISED THAT YOU ARE STILL PRODUCING THIS LIST ON YOUR SITE AFTER ALL THE PUBLICITY ON THIS ISSUE. PLEASE CONSIDER REMOVING THE LIST FROM YOUR SITE AS SOON AS POSSIBLE AND PLEASE CONFIRM THIS ACTION TO ME IN PERSON BY E-MAIL. MANY THANKS KECIA BARKAWI (LAWYER, ZURICH)
