Just to go a little bit more in that direction, I already have seen an
obvious one-line patch that caused a deadlock in another OS because due
to code location change and probably an additionnal cache miss on
specific part of the code, an existing synchronisation bug that was
never triggered started to effectively happen...
Besides, if you please 1000 users and cause problem to 2 of them because
they have broken hardware, I think you are going into the right direction.
>The important sections are more likely (ordered by priority):
> - bug fixes (e.g. aic7xxx)
> - support for additional hardware (e.g. ACPI update)
> - new features (e.g. XFS)
Bug fixes are meant to make the 2.4 kernel more useable right? So I do
not reallly see the utimate difference with other things in your
category. What I was asking is a rationnal way of chosing the
priorities. You gave me yours without real explanation.
The purpose of the original mail was to ask for discussion/clarification
on 2.4 development priorities (e.g something like the 2.6 todo list) and
a proposal to set up the priorities using generic targetted hardware
(server, laptop, desktop) as hint for requirement selection.
-- __ / ` Eric Valette /-- __ o _. 6 rue Paul Le Flem (___, / (_(_(__ 35740 PaceTel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76 E-mail: eric.valette@free.fr
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/