Re: Proposal - Defer discussion about SC and firmware until after the Etch release
Frans Pop <elendil@planet.nl> wrote:
> 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=20
> Social Contract.
There may be such people. However, I am not one of them, so this -
> There are others who feel that the world is not black and white, but that=20
- bashing of imaginary demons by comparison is ugly and off-topic.
> there are other categories, or that least that there are categories who do=
> deserve a less strict treatment than real code. These categories include=20
> images, documentation and firmware.
Maybe images, documentation and firmware should be treated differently
(although I question the concept of them deserving it), but they are
still present in debian as software. The basic freedoms sought by
the DFSG are still relevant and desirable for everything on the discs,
whether or not we need to make some small exceptions to get installable
discs for some systems.
[...]
> > > [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.
IIRC, the permission for alternative solutions is explicit in the proposal.
Ergo, it cannot mean you can no longer implement an alternative solution.
> > 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.
Noted. It's so far short of the required seconds - even those who said they
would second such a thing did not do so - that I don't intend to revise it.
Also, the proposal has been withdrawn, so I assume that all amendments now
fall, because there is no proposal to amend.
[...]
> > > 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).
!!! Is this suggesting that the current Debian RMs view development problems
that delay being releaseable as Somebody Else's Problem and that the D-I RMs
have been quietly waiting until it was too late, or what?
Apologies if I've misunderstood that,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Reply to: