Frans Pop <[EMAIL PROTECTED]> wrote: [...] > to the removal from the distribution (main) of "software" that could be
Please, drop the scare quotes on software. > [...] i. ensure that the Debian community has a good understanding > of the technical and legal issues that prevent the Debian > Free Software Guidelines from being applied to logos and > firmware in a manner that meets the needs of our users; s/prevent/affect/ else it assumes the outcome before the discussion (as well as being false). [...] > Some statistics to give an indication (this is based on my local mailbox > of d-vote for Aug/Sept for subjects containing "source" or "firmware" with > only some irrelevant subthreads deleted). > In total 465 posts from approximately 80 different persons. [...] > 16 From: MJ Ray <[EMAIL PROTECTED]> > In addition to these heavy posters, [...] Writing ~3 posts a week to a thread running at ~90 posts a week does not make one a heavy poster. > My impression was that numerically there were *more* people _in favor_ of > a more liberal approach (or at least of voting those proposals), but that > they found it sufficient to second the proposals, sometimes with short > comments, and not participate in the discussion. [...] Yes, there seem to be people not interested in participating in the discussion, or trying to form any consensus or compromise. Even some of the proposers have failed to answer key questions about their proposals. This should not be sufficient, but the project has rewarded silence in the past, so it encourages people to use that tactic. > VISION FOR THE FUTURE > [...] loading such packages > from contrib/non-free would imply that these sections have to be added by > default to the sources list for these users which is undesirable given the > aims of the project [1]. [...] > [1] This is also why I object to MJ Ray's amendment in > <[EMAIL PROTECTED]> as it codifies the solution > without having checked its practical implications. It presents an example of its implementation - I know it has practical problems, but it's the simplest example of the solution I could see, given the constraints. It does allow people to solve the practical problems by implementing a similar result in a better way. Why include an example? To avoid the "that's unimplementable" cry which some DDs have made against my suggestions in the past. > [...] There are probably only two people who come close > to his level of overall understanding of the installer (no, I'm not one of > them, I rank myself about fifth). I wondered several times why that is, and then I tried to get a working development debian-installer. This isn't the place, but for a start http://www.debian.org/devel/debian-installer/ seems more aimed at users and beta-testers than developers, yet it's in /devel/ on the site. So, I don't think that failing to understand the subtleties of debian-installer should disqualify people from the discussion, but it's quite right to say that we should listen to those who do. Which brings me to a related point: some participants in this discussion have been poor at mentioning vital roles they hold, or making it clear what hat(s) they are wearing. Sorry to break it to people, but 'see shy jo' is not that famous yet that it makes everyone remember 'ah, debian-installer'. The above message from Frans Pop at least mentioned being release manager in the run of text. [...] > So, my formal position as D-I release manager has to be: > "We will not accept any structural changes to support loading firmware in > the installer (not from main nor from elsewhere), > - if the release plan for Etch remains at 4 December 2006; > - unless both Joey Hess and I, after careful review of a finished and > tested proposed solution, decide that 1) it provides an acceptable > solution for all installation methods and architectures, 2) it poses no > risk of regressions or delays in the run-up to the release." In principle, would you accept the change as drafted by Joey Hess in <[EMAIL PROTECTED]> ? > The initiatives started during the discussion on d-vote to implement some > kind of support are appreciated, but they are too late for Etch! So, it seems fair to let people ask: did the release managers address this topic reasonably early enough in the release process and how can a repeat best be avoided for the next release? Personally, I think that agreeing non-free-hwsupport now is the best approach, even if it cannot be implemented in time for etch, an etch-ignore permission is approved and/or another approach is adopted instead later. Otherwise, it looks like the default will be that this issue will not get enough work until too late again, as in etch. > In my personal opinion they are also premature given the controversy that > exists over the question if firmware should really be treated as totally > non-free or rather be supported to some extend. Some of each and some besides, surely. Firmware isn't a whole indivisible class of things which has to be one or the other. Often advocates of the 'let in all non-free we want' seem to suggest it is, but it's not. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
