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

Re: Social Contract GR's Affect on sarge

Anthony Towns wrote:
> As this is no longer limited to "software", and as this decision was
> made by developers after and during discussion of how we should consider
> non-software content such as documentation and firmware, I don't believe
> I can justify the policy decisions to exempt documentation, firmware,
> or content any longer, as the Social Contract has been amended to cover
> all these areas.
> As such, I can see no way to release sarge without having all these
> things removed from the Debian system -- ie main.
> This will result in the following problems:


> 	* many pieces of hardware will not be supported by the Debian system
> 	  itself
> 	* firmware will need to be split out of the kernel into userspace
> 	  in all cases
> 	* firmware will need to be packaged separately from the
> 	  kernel/X in all cases
> 	* debian-installer will need to be rewritten to support obtaining
> 	  non-free firmware but not other non-free packages
> 	* firmware for drivers needed for booting (network cards
> 	  particularly) will need to be made available as udebs in
> 	  non-free, and separate non-free d-i images will need to be
> 	  made for people relying on that firmware

The above is not the only option left to us after this change of the
social contract, and aj's policy change based on it. We're actually left
with two choices:

a. Do as above, try to support all hardware that requires non-free
   firmware. Delay the release until sometime next year (according to

b. As firmware support is dropped from the debian kernel, document it.
   Refer angry users to debian-devel and Fedora. Release as soon as sarge
   is otherwise ready.

To me the choice between a. and b. comes down to some hard numbers that
I don't have. I'm interesting in maximising Debian's use, which means
maximising the number of users who can use it on their hardware, and the
number of users who choose to use it.

It seems lilkly that if we delay the release until sometime next year,
then stable will be uninstallable on a majority of new hardware at that
point. It will also be so stale that nobody wants to use it. This is
already becoming the case; it's why you see more users on debian-user
successfully installing with d-i, even in its current beta state, than
you see installing with the boot floppies.

If we release without support for given pieces of hardware, with it
documented what hardware is not supported, then at worst we lose the set
of users who have such hardware, plus those who give up on Debian
because they dislike this choice of pureness over pragmatacism. I don't
know how much hardware that will be; it's been somewhat reassiring to
learn that the tg3 driver works on most hardware w/o nonfree firmware,
and if I had a list of all the other modules that will be dropped, I
could get closer to an estimate of the numbers here.

There is also a possibility that unofficial images with uncastrated
kernels would be made to fill in the gaps; similar things happened in
woody after all, and it will be much easier to do with d-i.

What's currently strongly tipping me toward option b. despite not having
all the numbers handy, is that there's a good chance that if sarge is
delayed until next year, it is effectively delayed until when we would
have released sarge+1, if this mess had not happened. As such, a sarge
release now can only help us, since it will be better than no release
for some nonzero subset of our users.

If we do choose a., then we should finish getting beta4 out, and then
put plans for future betas on hold as we do the probably several months
of work needed to support split out non-free firmwares. If we choose b.,
then we should work with Herbert Xu and others to assess what drivers
will be removed, and get that documented, and otherwise proceed as

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: