Re: Ptrace hole / Linux 2.2.25

Jeff Garzik
2003-03-23T22:03:05Z

Martin J. Bligh wrote:
>>>I don't agree that's always been true by any means. It may currently
>>>be true, but that's far from a good thing. The current state of divergance
>>>the distros have from mainline 2.4 is IMHO the biggest problem Linux has
>>>today.
>>>
>>>The distros inherently have a conflict of interest getting changes merged
>>>back into mainline ... it's time consuming to do, it provides them no real
>>>benefit (they have to maintain their huge trees anyway), and it actively
>>>damages the "value add" they provide.
>>
>>Just to underscore Arjan's point: non-mainline patches are very actively
>>discouraged at Red Hat. As time progresses the maintenance cost of EACH
>>non-mainline patch increases. Non-mainline patches do not get the
>>benefits of wide community testing, review, and feedback. Further,
>>Red Hat employees in my experience typically land patches in the community
>>_first_ -- witness my netdriver work (goes me -> Marcelo -> RH), DaveM's
>>net stack work, and Alan's -ac tree.
>
>
> Right ... people seem to have taken more than I meant from this, and taken
> it more personally than it was intended. I do believe there is at least
> some conflict of interest ... but that doesn't mean people are controlled
> by it.
>
> After some other side conversations, perhaps it would be useful to clarify
> that the appearance of a problem is more that we don't *see* patches getting
> submitted or accepted very often. That doesn't necessarily mean they aren't
> getting submitted.

I see a lot of new Red Hat work getting discussed, landing in the 2.5
tree, and then getting backported as a value-add 2.4 feature for an RH
kernel. Other stuff is "hack it into stability, but it's ugly and
should not go to Marcelo."

IMNSHO this perception is more a not-looking-hard-enough issue rather
than reality.

I have no idea about UnitedLinux kernel, but for RHAS I wager there is
next to _nil_ patches you would actually want to submit to Marcelo, for
three main reasons: it's a 2.5 backport, or, it's a 2.4.2X backport,
or, its an ugly-hack-for-stability that should not be in a mainline
kernel without cleaning anyway.

> But the divergance of 2.4 is still a massive issue ... whatever the
> underlying causes are.

Can you actually quantify this divergance?

From actually _looking_ at RHAS for submittable patches, it seems to me
like mostly 2.5-backport patches in 2.4, or, bandaid-until-2.5 fixes
that don't belong in mainline.

Jeff