[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal - Defer discussion about SC and firmware until after the Etch release

On Tuesday 12 September 2006 13:04, MJ Ray wrote:
> 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.

No, I don't think so. There are people who feel that everything that is not 
hardware is software and this seems to be the current definition of the 
Social Contract.
There are others who feel that the world is not black and white, but that 
there are other categories, or that least that there are categories who do 
deserve a less strict treatment than real code. These categories include 
images, documentation and firmware.

> > [...]     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.

No, I agree. "relatively heavy" then? There was only one person in the list 
who's posting behavior I'd really qualify as excessive.

> > [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.

The problem with "hardcoding" the solution in a GR, especially if you know 
there are practical problems, is that, if accepted, you can no longer 
implement an alternative solution that would resolve those practical 
problems even if it is in the spirit of the resolution.

> Why include an example?  To avoid the "that's unimplementable" cry which
> some DDs have made against my suggestions in the past.

Then I'd suggest moving the example outside the actual ballot.

> > [...] 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.

The website is totally dedicated to the development version of the 
installer. The information you are looking for can be found on the wiki, 
which is linked from the page.
Feel free to ask for specific help either on the d-boot list or on #d-boot.

> > 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> ?

Yes. Except (as explained in my original mail) that I'm not really in favor 
of taking it from non-free as that would condemn such users to have 
non-free in their sources for the installed system as well.

> > 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?

Which release managers are you talking about here?
Debian RMs? In that case the answer is no, but the question is if it is part 
of their job description to manage individual development issues.
D-I RMs? In that case the answer is that we have been waiting for concrete 
implementation of a split in the kernel so that we would know what we would 
have to work with. The first real implementations of that split happened 
too late to make a difference (for the reasons I've set out).

Attachment: pgp4MgLkzkcXg.pgp
Description: PGP signature

Reply to: