Re: Bits from the 2IC
Holger Levsen wrote: > Hi, > > On Tuesday 20 February 2007 15:56, Gustavo Franco wrote: > > It wasn't too polite from Steve, IMHO. He lost a great opportunity to > > avoid use d-d-a to promote his campaign even before the campaign > > period starts. Please Martin, just check the timing of the things and > > how it was planned. > > While I do think it would have been better, to first send the bits and then > the nomination, I believe it was an honest mistake. And in a way I'm glad > that Steve (DDs running for DPL in general) is not a perfect politican ;) Not to forget that his summary was long awaited already and he would probably have sent it independent of running for DPL or not. Regards, Joey -- GNU GPL: "The source will be with you... always." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question to the Debian community ... (Was: Question for Sam Hocevar "Gay Nigger Association of America")
Sven Luther wrote: > The DAMs, who did not follow their own procedure, who did refuse to > provide the dates of the expulsion requests, because they knew well > enough that it would show the irregularities of the procedure, who > ignored the 70:7 expressed opinion of the DDs against the expulsion. The Just for the record: If they ignored it they'd expelled you and not suspended your account for one year. That *is* a difference. Regards, Joey -- A mathematician is a machine for converting coffee into theorems. Paul Erdös -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Raphael Hertzog wrote: > 1/ I know people who want to maintain package but don't want to be DD. > > The time involvement required to be DD is far bigger to the one required > to be able to maintain properly a single package. And I don't want to > lower the barrier to become DD because the role of DD are critical in > the success of Debian (while the role a maintainer of a single package is > not). Could you explain how the "time involvement required to be DD" for a person who only wants to maintain one package is higer when they are a DD contrary to not being a DD? Please ignore going through NM since this is only the entry process and doesn't matter at a later stage. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Pierre Habouzit wrote: > Another question I have is that basically, I don't grok why it's > harder to give DM's uploads rights, than NM's an account. DD implies an account on ~20 machines. Having only upload rights does not imply this and the outcome of a fuckup in a .deb will only cause an incident on these machines ~2 years later when the distribution has become stable. > Well, basically I quite concur with Bastian on the fact that it'll > likely hide some current problem, and prevent us from fixing them. Is > there _that_ many people around there that need upload rights _and_ > don't care about voting rights, reading -private, and so on ? I'm > worried with this kind of second class developers thing. I mean, as a > staging area maybe, but I don't like the fact that people could stay in > it for basically, forever. Regarding some sort of staging area, it may be worth to consider introducing upload permission to a NM who is in a certain stage of the process, maintains >= 1 package in the archive and when such a permission has been requested from their AM? Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Raphael Hertzog wrote: > > > The time involvement required to be DD is far bigger to the one required > > > to be able to maintain properly a single package. And I don't want to > > > lower the barrier to become DD because the role of DD are critical in > > > the success of Debian (while the role a maintainer of a single package is > > > not). > > > > Could you explain how the "time involvement required to be DD" for > > a person who only wants to maintain one package is higer when they > > are a DD contrary to not being a DD? Please ignore going through NM > > since this is only the entry process and doesn't matter at a later stage. Thanks for not answering my question. Therefore I assume that the answer would be "zero", i.e. it's the same time involvement required to maintain a package for both a DD and a DM. Unfortunately, this renders your argument bogus in my opinion. > I'm sorry I don't understand why I should ignore the NM process. Because 1 It's a one time issue even if the time period involved can be quite long and 2 Didn't you say that the DM thing is not meant as workaround about dificiencies in the NM process? If this thingy is only meant to bypass NM since it sucks or is pink or whatever, just say so and the proposal will be considered as such. The NM process after all is meant to help new maintainers become skilled maintainers of packages. If we want to get them maintain packages without going through NM we should not create a new stage but drop or restructure the NM process. IMHO > The skills we ask every Debian developer to have are far larger than the > skills required to maintain a package (which uses only one languague). We > ask DD to be able to package almost anything and to prove us that they are > able to document themselves on any subject so that if they decide to > package something more complex, we're confident that they'll be able to do > it (same story for NMUs). When somebody becomes a DM without going through the NM process and thus has no skills on packaging besides those required for the very package they started with and now wants to package $cool_kde_application which requires $not_so_cool_kde_libraries they also need to package how are they supposed to do so? Just go ahead without knowing what to do? Or are DMs only allowed to maintain the packages they started with as long as they haven't become more complex so that they can't exceed their packaging skills? I fear that the DM thingy is just invented to get more people maintain packages in Debian without becoming properly involved, eventually not giving the same care a normal DDviaNM would give and thus Debian ending up with a universe of broken packages. That's most certainly not what I would like Debian to become in the future. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Konstantinos Margaritis wrote: > > * 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. > Also, expect many errors at least on the initial burst of package > uploads, which will mean extra load on QA people, RMs (who will > actually have to fix the RC bugs before release), because new DMs, > just like new DDs (and old), are more prone to make mistakes, and > although undestandable, unless they are watched over by a > sponsor -like the situation is now with NM- many mistakes will go > overlooked. Do we really want to do that? The RMs could in return request the DMs removal. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Raphael Hertzog wrote:
> > > If you want to improve the NM process, fine, the NM team awaits your help.
> > > But don't block other initiatives to improve Debian for reasons which
> > > are dubious.
> >
> > So my reasons are dubious? I guess I should let you vote for me and just
> > sign the ballot since your reasons are more reasonable than mine? I
> > thought we're discussing here?
>
> We're discussing, but your objections are rather superficial IMO.
> It looks like "it would be best if we could have integrated that more
> tightly in the NM process and I'm not sure if we couldn't do better" and
> not an objection like "this is broken because X and Y".
>
> So I suggest you to not stand up against this proposition if you're not
> convinced that this would negatively impact Debian. It might be that it
> doesn't have as much success as I expect, but then we haven't lost much by
> tring it out.
I wonder why/how we managed to degrade this discussion into a sparkling
flame with personal attacks ('your reasons are dubious', 'don't stand
against it') so quickly.
Regards,
Joey
--
If nothing changes, everything will remain the same. -- Barne's Law
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Raphael Hertzog wrote: > > 1 It's a one time issue even if the time period involved can be quite > > long and > > A package maintainer that can't upload during one or two years and who has > to chase sponsors indefinitely will end up demotivated and won't finish his > NM process. (It's not something which is true of everybody, but it's > certainly true for a significant part of small contributors) Then we should fix the NM process instead and not create a new level of buerocracy and second class maintainer officially. > > 2 Didn't you say that the DM thing is not meant as workaround about > > dificiencies in the NM process? > > I did. IMO the length of the process of the NM is a feature not a bug. I > want DD to be reliable like they are. On the other hand, I want people > with less time to be able to contribute a bit nevertheless. You need to > compromise on other aspects to achieve this. I'm sorry, but to me this does not exactly sound convincing, more the contrary. I'd be much happier if you'd start with a clone of mentors.debian.net for contributors who want to maintain packages without becoming Debian developers and let users decide if they want to add that repository to their APT sources. (Suddenly experience with dotdebian php packages come to my mind) Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Kalle Kivimaa wrote: > Thijs Kinkhorst <[EMAIL PROTECTED]> writes: > > Can you be a bit more verbose as to why you could not just refrain > > from using some rights that a DD has? > > I was close to resigning because I thought the Debian community was > taking active steps to a wrong direction. I wouldn't have wanted to be > a part of such a community, even though I would have liked to continue > contributing to the technical project. As such, I would not have > wanted to have the voting rights. Hmm. By continueing to maintain your packages but losing voting rights you would still be part of the community but without the slightest chance to change anything. I guess, I didn't get your rationale. Err... Care to help me? Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Mark Brown wrote: > In addition to the practical issues that Raphael raises a number of > people have expressed a desire to maintian packages (and otherwise be > involved in the technical side of Debian) without having any involvement > in the political side of Debian. Well, they are free to decide not to participate in political or philosophical discussions and are also free not to vote. Voting is a right not a duty after all. > It's true that people can always just > ignore these things but some people feel a sense of obligation to take > part in them and are more comfortable with a status that explicitly > excludes doing that. I don't understand that but maybe some of these people could speak up - even it would mean to become involved with a political discussion in Debian. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Benjamin BAYART wrote: > Raphael did kindly give me a pointer to your running discussions, which > is of interest for me, since I'm one of the potential "DM" in a near > future, and I wanted to give my point of view on that topic, and to give > a few comments on the text. Thanks for your mail. > As a free software user/developper, I want to fix my system, since I'm > able to do that. As a nice man, I'd like to provide the fix. > > But I have no time to become a whatever developper, or regular > contributor, and to involve in a long and time consuming process. I > know points to be improved in Debian, in the aspect which is of interest > for me. There are two ways to do that: > - I make my own custom package that fix the bug (or add required > software), I use it, I make it available to my friends on my web > site, and that's all; > - I try to make it available in Debian. I assume that this refers to different packages at different times. I interpret this so that you don't want to become the maintainer of a particular package but instead be able to fix various stuff that broke. Is that correct? > I've discussed that with quite some DD and NM: I do not want to be a NM, > since I do not want to become a DD. There is no DD available to work on > the packages I need. I am ready to contribute the technical stuff needed > in Debian, no more, no less. I am ready to learn better the rules on > "how to package", but I'm not ready to spend time on the Debian project > by itself. It is interesting, but I already have my own crusades, I > cannot assume one more heavy involvement. > > During my discussions with DDs, I found there is currently no solution > for me to help: I can send the bud report, with the patch, then it will > keep sleeping in BTS for years, and the package will be dropped... > because I reported the bug and those were not fixed! > > Have a look at bug 231275 on dvidvi: > - I posted the patch in Feb 2004, fixing a severe problem on the soft > - it was fixed in May 2005 > > 15 months, while with DM, it would have been only few days... No. You won't be able to fix it unless you have become a DM with exactly the dvidvi package and thus are allowed to upload a fixed version. Otherwise you aren't and need to go through senting a patch and links to the BTS and/or sponsoring via a DD. > 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. Regards, Joey -- Linux - the choice of a GNU generation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Raphael Hertzog wrote: > On Sat, 23 Jun 2007, Joey Schulze wrote: > > > 15 months, while with DM, it would have been only few days... > > > > No. You won't be able to fix it unless you have become a DM with > > exactly the dvidvi package and thus are allowed to upload a fixed > > version. Otherwise you aren't and need to go through senting a > > patch and links to the BTS and/or sponsoring via a DD. > > I'd gladly sponsor Benjamin if I knew that I don't have to do it > endlessly... right now I'm not motivated to help him fix such packages > because it imposes too much burden on me on the long term. This perspective does not exist with the DM proposal as it has turned out, unless he wants to maintain a single package (or more than one package), but from what I read this does not seem to be the case. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Benjamin BAYART wrote: > > > During my discussions with DDs, I found there is currently no solution > > > > This is where you are wrong. The correct way to handle this, is to be > > part of a team, working on the tex packages and providing fixes, and if > > there is an upload needed, a DD member of the team can make the upload. > > > > This is how many of the debian teams involving non-DDs work, and is the > > way of the future for debian, to have more team maintained package > > groups. > > That can be part of a solution. As far as I remember, there was nothing > like a TeX team last time I tried to bing patches to such software, but > perhaps I did not look closely enough. At least this is the case for the TeX Live packages included in Debian. They even are officially maintained by: | Maintainer: Debian TeX Maintainers <[EMAIL PROTECTED]> At least in case of TeX Live packages there might be a way for you to contribute fixes directly from time to time. > 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. Wow. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: %20Re: Debian Maintainers GR Proposal
Benjamin, it seems to me that neither NM nor DM is suited for you. Reporting broken stuff and optionally attaching a patch later or at the same time is the way to go. In case of TeX packages, there's the TeX maintainer team that will probably take care of your fix. In case of other packages, when the maintainer does not respond, it may be a good idea to ping the QA team at [EMAIL PROTECTED] so that one of them may take your patch, apply it and upload a fixed package. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: %20Re: Debian Maintainers GR Proposal
Pierre Habouzit wrote: > If you are _that_ interested in helping the TeX packaging team, join > it, I think it's co-maintained on alioth, you just need an alioth > account, it takes a few minutes to have one, and you'll have to ask the > pkg-tex people to give you commits rights, which should do what you > really want. I agree that this seems to be more of the kind of privilege you are seeking. Alioth grants access to arbitrary people who haven't become Debian developers yet as well, so that's most probably the way to go. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: %20Re: Debian Maintainers GR Proposal
Benjamin BAYART wrote: > Another case come back in my mind: pandora. Those fonts have been > available with TeX since years and years. They have been removed from > Debian/main for good reasons (wrong license: free for non commercial use). > In my mind, in such a case, it should be mandatory to move the > corresponding software in Debian/non-free, instead of dropping it. This happens when the maintainer is happy to continue maintaining it which is not always the case. Depends on the maintainer and their feelings. > It is often not done because the maintainer do not have time enough to > do that, it can be sorted out by a DM who would handle that. When the DM wants to maintain the package in non-free that could be possible. If a non-free package would be a sufficient enough reason for granting DM permissions, that is. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Kalle Kivimaa wrote: > I second the following proposal (by my count it is still missing at > least two seconds, if anybody is interested in seconding). I believe it has way to many flaws to be seconded. > Debian Maintainers Proposal > > The Debian Project endorses the concept of "Debian Maintainers" with > limited access, and resolves to > > 1) A new keyring will be created, called the "Debian maintainers keyring". >It will be initially maintained in alioth subversion using the jetring >tool, with commit priveleges initially assigned to: > > * the Debian Account Managers (Joerg Jaspert, James Troup) It would be nice to know what the DAMs think about this, especially James, since he's one of the reasons this proposal came up since the last stage before account creation takes oh so long. If he's totally opposed to this proposal, I'm not sure how much value it has at all. > * the New-maintainer Front Desk (Christoph Berg, Marc Brockschmidt, > Brian Nelson) > * the FTP masters (James Troup, Ryan Murray, Anthony Towns) It would be nice to know what the FTP masters think about this proposal (the others, not Anthony). > * the Debian Keyring maintenaners (James Troup, Michael Beattie) > * the Jetring developers (Joey Hess, Anthony Towns, Christoph Berg) The maintainer of software initially used should not per se have commit rights and decide who is granted. They should have proper rights to maintain the software which others are free to use, but nothing else. > 4) The initial policy for Debian developers who wish to advocate >a potential Debian maintainer will be: > > * Developers should take care in who they choose to advocate, > particularly if they have not successfully participated as an > Application Manager, or in other mentoring roles. Advocacy should > only come after seeing the individual working effectively within > Debian, both technically and socially. > > * Advocacy messages should be posted to debian-newmaint or > other relevant public mailing list, and a link to that mail > provided with the application. > > * If a developer repeatedly advocates individuals who cause > problems and need to be removed, the Debian Maintainer Keyring That "and" may require to be substituted into an "or". > team may stop accepting advocacy from that developer. If the > advocacy appears to be malicious or particularly careless, the > Debian Account Managers may consider removing that developer > from the project. > > 5) The intial policy for the use of the Debian Maintainer keyring with the >Debian archive will be to accept uploads signed by a key in that keyring >provided: > > * none of the uploaded packages are NEW > > * the Maintainer: field of the uploaded .changes file matches the > key used (ie, maintainers may not sponsor uploads) Should read "matches the address and name of the key used", I don't want to have GPG keys used in the maintainer field please! > * none of the packages are being taken over from other source packages > > * the most recent version of the package uploaded to unstable > or experimental lists the uploader in the Maintainer: or Uploaders: > fields (ie, cannot NMU or hijack packages) > > * the usual checks applied to uploads from Debian developers pass I'm missing any mention about taking over arbitrary packages since it was said that a DM can not simply upload arbitrary packages but is only permitted to upload them they came up initially and which were reviewed. I still believe that this proposal is flawed and we should address the real issue it secretly tries to solve. We should instead grant NM applicants permission to upload the packages they work on during their NMship *after* their AM has reviewed the packages and *after* they have demonstated to be competent enough to properly maintain them, even before they have finished NM and are only waiting for DAM activity. It may also be worth re-evaluating NM with regards to the difficulty and relevance of questions NM applicants have to answer correctly. Should it turn out that we want too much, we may alter the process a little bit. We should not install the DM thingy in the proposed form. Regards, Joey -- Given enough thrust pigs will fly, but it's not necessarily a good idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal
Anthony Towns wrote: > On Wed, Jun 27, 2007 at 10:26:46AM +0200, Joey Schulze wrote: > > > 5) The intial policy for the use of the Debian Maintainer keyring with the > > >Debian archive will be to accept uploads signed by a key in that > > > keyring > > >provided: > > > * none of the packages are being taken over from other source > > > packages > > > * the most recent version of the package uploaded to unstable > > > or experimental lists the uploader in the Maintainer: or > > > Uploaders: > > > fields (ie, cannot NMU or hijack packages) > > > * the usual checks applied to uploads from Debian developers pass > > I'm missing any mention about taking over arbitrary packages since it > > An arbitrary package's most recent upload will not have the person trying > to take it over listed in the Maintainer: or Uploaders: field. *ponder* Was this meant to be the case for the previous package and not the newly uploaded one? If so, this should be written down. > > I still believe that this proposal is flawed and we should address the > > real issue it secretly tries to solve. > > I think the DM level of access is useful even if NM were to be working > perfectly. Your insinuation that I've got a secret agenda for this is > offensive and unwarranted. FWIW, you came up with a secret agenda idea, not me. Thanks for spitting at me. Regards, Joey -- Given enough thrust pigs will fly, but it's not necessarily a good idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers GR Proposal - Use Cases
Pierre Habouzit wrote: > > On 28/06/07 at 05:49 +, Lucas Nussbaum wrote: > > > Yes, please sent it, I'll publish it somewhere. > > > If you are not too ashamed of your scripts, I'd like to see them as > > > well, if you don't mind. > > > > Hi, > > > > Thanks to Felipe, the lists of possible candidates are now public. See: > > > > * list of non-DD Maintainers or Uploaders, sorted by the number of > > packages: > > http://qa.debian.org/~lucas/dm_gr_candidates/maintainers_uploaders_no_dd_sorted.txt > > > > * list of non-DD Maintainers (Uploaders ignored), sorted by the number > > of packages: > > http://qa.debian.org/~lucas/dm_gr_candidates/maintainers_no_dd_sorted.txt > > hmmm, what looks comforting, is that in the say top 20, I see quite a > few very valuable and regular (and for what I know skilled) > contributors, but those are not DD because of NM, and DM is not really > what they need (I mean, I'd really like to see their long waiting AM > report be validated, and account created...). It would probably be helpful to clean the listing from those in NM. Regards, Joey -- Reading is a lost art nowadays. -- Michael Weber -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
Holger Levsen wrote: > Hi, > > On Monday 31 March 2008 21:45, Moritz Muehlenhoff wrote: > [wordpress] > > FWIW, it's orphaned since yesterday. But let's keep it in Lenny > > as well, I no longer care. > > Hu? > > Can you please elaborate? "Orphaned, pretty bad security record, let's keep > it" -> I don't understand. Maybe it's meant cynical? Regards, Joey -- Everybody talks about it, but nobody does anything about it! -- Mark Twain Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Resolving DFSG violations
Robert Millan wrote: > > I hereby propose the following General Resolution to stablish a procedure > for resolving DFSG violations: I believe that the Debian project is way better off without this General Resolution and with the rules and social contract as they are to date. Even worse, I have the strong feeling that the options proposed will hurt the Debian project, delay lenny and future releases. It should not be voted on. DFSG-nonfreeness is currently some sort of a grey zone which allows us to release lenny at all. We should all know (at least by know) that we still have some skeletons in the closet and we all know that we need to work on fixing these problems. We should work on fixing these problems with upstream instead of continueing this discussion. Regards, Joey -- Life is too short to run proprietary software. -- Bdale Garbee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: new proposal
Andreas Barth wrote: > * Matthew Johnson ([EMAIL PROTECTED]) [081110 22:03]: > > On Mon Nov 10 12:09, Russ Allbery wrote: > > > Stephen Gran <[EMAIL PROTECTED]> writes: > > > > > > > I take it then that you're fine with the discussed DFSG issues in glibc > > > > for release? Is there a particular reason that bit of software doesn't > > > > need to meet the DFSG, or is it just that it's particularly inconvenient > > > > to release without it? > > > > > > I think it's fairly obvious that glibc meets the DFSG in practice, in that > > > no one is ever going to attempt to apply the ambiguous and badly-written > > > portions of the Sun RPC license in a way that might violate the DFSG. > > > It's certainly not an ideal situation, but on the spectrum of licensing > > > issues that we might ignore it's not one that would keep me up at night. > > > > > Also, it's in the process of being resolved. There are (according to > > another thread) talks with Sun about explicitly licensing it under a > > better licence. > > The stuff in the kernel is also in the process of being resolved. Slowly, but... Regards, Joey -- ( ) go ahead, you can blog everything in this mail ( ) please don't blog the personal stuff in this mail ( ) this conversation never happened -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firmware
Luk Claes wrote: > Hi > > As probably many of you know, the most heard criticism from users and > press on Lenny's release is lost hardware support because of missing > firmware. Users and press are complaining that their servers don't have > network anymore after an upgrade or that their notebooks cannot be > installed via wireless... > > It's of course possible to load firmware from extra media during > installation or install the right package (from non-free) when booting > back to an older kernel (to have network again) to be able to use the > network with the new kernel... > > What do people think of a new vote regarding the status of firmware? One > of the options can probably be Peter Palfrader's proposal [1]. I would rather like to keep binary firmware blobs outside of Debian/main and maintain them in Debian/non-free with improved and easy ways to load them during the installation. We might require a new vote in order to release squeeze at some date. We should be able to release squeeze even with non-free binary firmware data included in the kernel. However, we should rather try to move these blobs into separate files (in Debian and upstream). However, this requirement should not keep us from releasing. Regards, Joey -- Still can't talk about what I can't talk about. Sorry. -- Bruce Schneier -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
