Re: Ptrace hole / Linux 2.2.25

[Jeff Garzik <jgarzik@pobox.com>]

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