Hey, I'm still European, and that gives me the God-given European right to
needle other Europeans.
[ For our US audience: Europeans basically have a mild and reasonably
friendly dislike for each other. Swedes think that Finns are drunkards,
Finns think that Swedes are good at tennis and singing but not much
else, everybody mildly dislikes the French but likes their food, and
nobody understands how the British survive on the slop they eat.
And everybody jokes about Germans being an army of humorless worker
bees.
None of the stereotypes are actually _true_, but many of them have some
small kernel of truth to them that just gets exaggerated. ]
> So, what do you suggest to remedy the situation? The ISDN updates are dearly
> needed by the masses, your argument (which I completely agree with) with the
> ISDN developers non withstanding.
>
> What about if you both get over it: You _once_ accept the big patch so we can
> resolve the situation right now, and the i4ldevelopers promise to feed you
> smaller patches in the future so it never occurs again.
For 2.2.x we don't have much choice - either it dosn't get updated at all,
or it gets updated in one large fell swoop.
For 2.3.x the choices are also fairly limited. Most of them basically
involve one large initial sync patch, and then future patches in a more
timely fashion. I don't think we can synch up reasonably any other way,
although it might be nice to have the initial larger sync be done on a
per-driver basis at least to some degree.
The thing is, that before I accept the large sync, I really want to get
the issues out in the open, and I really do want to make sure that when
the 2.5.x development tree opens, the ISDN code won't be in the same shape
as it is now, with large pending patches.
For example, I really want ISDN developers to try to be as disciplined as
other devlopers are during a feature freeze. Instead of thinking "Oh, the
standard kernel has a feature freeze, so we'll just do all our development
in the CVS tree and sych up in one large go", the ISDN people too should
understand what the feature freeze is all about: testing a stable system,
and making sure that the bugs at that time get ironed out and _nothing_
else. No secret CVS tree activity on the side etc. It's about hammering
something out that you can live with for a year or two there-after WITHOUT
telling people to upgrade to some completely new CVS tree version.
Now, "disciplined as the other developers" is probably an oxymoron. None
of the Linux feature- or code-freezes have been all THAT disciplined, but
at least people tried, and we basically succeeded reasonably well in the
end.
And remember: feature-freeze and even code-freeze does not mean that bugs
don't get fixed, it just means that people really ONLY concentrate on
finding the bugs. It should be something ISDN developers need to do
occasionally too, and this all really shouldn't be all that big of an
issue. It's just that historically it has really not worked at all..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/