>>">>>" == Ian Jackson <[EMAIL PROTECTED]> writes:
>>>> Manoj Srivastava writes ("Re: [EMAIL PROTECTED]: 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.
Every package maintainer has to decide on what to ship in
their package -- and some of the consideration taken into account
while making that decision are the amount of trouble the code in
question would cause; not just known bugs, but the potential for
problems, and the impact on unrelated area (fbcon modules).
These decisions lie with the maintainer for a reason -- they
have taken charge of the package, and are responsible for it -- and
the tech committee does not have the familiarity with the package to
make decisions that are more intelligent than the maintainers.
>> 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.)
And in your estimation 3 people are a huge set? How does 3 bug
reports in any way invalidate what I said?
>>>> The alleged cost of the non modular VESA fb is still a mystery to me.
>>>> What bad consequences does it have ?
crfuty code that is not keeping up with modern kernel trends
is always a problem. Also, this is a thin wedge in the door -- you
include a low interest peice of code like this in, and all any other
related crufty old peice needs to get into the kernel, despite the
judgement of the maintainer, is 3 people who are interested in
it. Heck, I can find 3 people who are interested in _anything_.
>> 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.
>>>> 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.
Which counts for naught if the individual members do not take
overriding developers and micromanaging packages based on what
appears to be little more than whimsy as a grave matter.
manoj
--
progasm: the feeling you get when your code works the first time
uunet!sugar!karl (hm) Keeping 255 messages and deleting
158. [EMAIL PROTECTED] (wk) re
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
