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

Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]



Manoj Srivastava writes ("Re: [herbert@gondor.apana.org.au: Re: Bug#161931:  kernel-image-2.4.19-k7: VESA driver for console]"):
> [Raul:]
> > I made an earlier comment on that discussion thread:
> >   "This is an argument for the kernel architects.  We're not kernel
> >    architects, however -- we're distributors.
...
> 	You are making an assumption that thre is intelligent desing
>  -- thet there is a coherent body of kernel architects, that encompass
>     all subsystems and modules.

No, Raul is not making that assumption.  He's just pointing out that
the decisions about kernel architecture need different considerations
to the decisions about what to ship in a distribution.

We may well agree or disagree with the current kernel structure, but
that's not what is being discussed here.  The point about modularity
of the kernel is relevant when talking about how to implement new
kernel features, and whether and how to restructure the kernel.

I don't think it's relevant when we're trying to decide what to ship.

> 	I must confess that I can't imagine that the set of people who
>  a) Can't live with text mode
>  b) Can't use X
>  c) Won't compile their own custome kernel
>    can be very large at all.

This hypothesising doesn't explain why three separate people have
already filed bug reports about this.  (Also, it's not really accurate
- you say `can't live with text mode', but apparently sufficiently
good text modes are not always available without VESA fb.)

> 	It all boils down to a non technical judgement call -- whether
>  the worth function of modularity offsets the utility of a precompiled
>  kernel containing vesafb for what maybe an infinitesimal audience;
>  and whether we can come up with a convincing enough case to override
>  a maintainer.

The alleged cost of the non modular VESA fb is still a mystery to me.
What bad consequences does it have ?

> 	I reiterate, overriding the maintainer must never be trivially
>  undertaken, and ought not to be done on guess work, or without a
>  strongly defensible case. None of which I see at the moment.

I disagree most fundamentally.  Nearly all actual disputes will
involve cases where there is doubt and uncertainty, and will also
often include situations where there is disagreement about the value
of one thing versus the value of another.

We already have the 3:1 supermajority rule to prevent us from
overruling maintainers in cases of real doubt; we already can't
override a maintainer's decision unless we have (near) unanimity.

We have to realise that maintainers are human, and that therefore they
will sometimes make mistakes.  Sometimes they'll been convinceable,
but sometimes - also because they are human - they'll not be
convinceable, even if they are wrong.  We should not adopt a view that
says that the maintainer's opinion on a difficult question is
necessarily right !

If you, Manoj, actually agree with Herbert on this question, then you
should obviously vote accordingly.  But if you agree with what seems
to be the position of Raul and myself, that including VESA fb has real
benefits (which are admittedly hard to measure) but no significant
costs, then I think you should vote accordingly.

Ian.



Reply to: