Re: Proposal - Defer discussion about SC and firmware until after the Etch release
Frans Pop <elendil@planet.nl> 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 <mjr@phonecoop.coop>
> 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
> <[🔎] 20060905122545.1178DF6CBE@nail.towers.org.uk> 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
<[🔎] 20060905212853.GA13929@kitenet.net> ?
> 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
Reply to: