On Tuesday 12 September 2006 13:04, MJ Ray wrote: > Frans Pop <email@example.com> 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). OK. > [...] > > > 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 <firstname.lastname@example.org> > > 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. > >  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).
Description: PGP signature