* Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: > Hi Ingo, > > On Sun, 14 Sep 2008 20:36:29 +0200 Ingo Molnar <mingo@xxxxxxx> wrote: > > > > * Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: > > > > > > Well, its not really that difficult, you just have to remember that x86 > > > is not the whole world [...] > > > > [ ... just used by 90%+ of our active testers/developers ;-) ... ] > > An irrelevant argument in this case. why is the actual usage distribution of Linux irrelevant? We make maintenance and testing prioritization based on usage and popularity on a daily basis: for example an unfixed bug in ext3 can easily stall an -rc or a stable release - an unfixed bug in freevxfs wont. > > hm, you seem to have a bias for powerpc, but you should realize that > > And you seem to have a bias for x86, so what! Well, having a bias towards the most popular code and most popular devices and platforms is not just acceptable and it is not just common sense - it's also a basic required skill from any Linux subsystem maintainer. Ignoring the most popular usage would be silly and counter-productive. And that requirement can be turned around to a certain degree: having an unreasonable bias _against_ popular platforms is counterproductive. I.e. you should weigh whether forcing the unreasonable use of our testing and development resources is good for Linux. > > cross-building for 20+ architectures (i.e. increasing the testing > > overhead twenty-fold), to cover the remaining <10% of the test space > > is unreasonable: for many developers it's not just virtually > > impossible in practice but also often a serious waste of time. > > I am not asking for that. > > > We want to push unreasonable work to those who depend on the result > > of that unreasonable work - i.e. users/developers of those platforms > > - not everyone else. We dont want to hinder the progress of Linux > > with blindly requiring all patches that happen to touch common .c or > > .h files to successfully build on 20+ odd architectures. > > But doing at least a simple grep for usages of the thing you are > changing, that is not unreasonable ... especially if you are changing > (usually not well defined in the first place) interfaces that the > architectures have had to implement (as was the case here). this assumes that the connection is realized. It was not realized in this case. > > ... anyway, no real arguments about this specific case, if a > > fix/report is available we'll integrate/fix the issue. > > Thanks. > > Besides, Ingo, many of the TIP trees (as I understand them) are not > x86 specific, so expecting them to build on more than one architecture > is not unreasonable. This is part of the job of the integrator ... we cross-build them (and fix the bugs, if any are found), but it's all driven by demand really or when we suspect there might be cross-arch breakage (it wasnt in this case). If i have the choice between analysing and fixing a bug that was reported by a real user and spending hours on cross-builds i do chose the one that helps Linux more. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
