linux-kernel - Re: XFS problem in 2.6.32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTimMhZWhUN3w_9Qapsqcic2_VCP0sg@mail.gmail.com>
Date:	Wed, 8 Jun 2011 10:16:59 -0400
From:	Mike Snitzer <snitzer@...hat.com>
To:	"Ted Ts'o" <tytso@....edu>, John Kacur <jkacur@...hat.com>,
	Stefan Priebe - Profihost AG <s.priebe@...fihost.ag>,
	david@...g.hm, linux-kernel@...r.kernel.org
Subject: Re: XFS problem in 2.6.32

Ted,

On Wed, Jun 8, 2011 at 9:38 AM, Ted Ts'o <tytso@....edu> wrote:
> On Wed, Jun 08, 2011 at 10:00:39AM +0200, John Kacur wrote:
>
>> Ok, I don't speak for my company, and your point about not expecting
>> people to do this work for you is valid, however I don't see why you
>> need to take potshots at Red Hat
>
> It wasn't a potshot; if it is true, it is a completely rational
> economic argument that is completely within the bounds of the
> requirements of the GPL, and with LKML community standards.
>
> The reason why I say it is because of (a) http://lwn.net/Articles/430098/,
> and (b) a few months ago, when I quietly floated starting a new
> long-term stable kernel series that a number of companies would
> maintain cooperatively, I was told, privately, that such a proposal
> would not likely be received positively by Red Hat management because
> of the reasons behind the policy instituted by (a).

OK, you seem to think you have it all figured out and that your Red
Hat contact knows everything there is to the Red Hat kernel
engineering development process.

However, it doesn't jive with what I know or how I (and my coworkers)
work on a daily basis.

Since we're referencing lwn.net articles please have a look at these
comments that I previously made on this subject of RHEL and stable@:
http://lwn.net/Articles/431317/
http://lwn.net/Articles/431420/

<snip irrelevant tangent about GPL>

>> I'm not even claiming that these are typical stats, but as just a
>> quick check on your statement, the contributions for one stable
>> release are in the same ballpark as everyone else.
>
> Nah, that just means that commits which are labelled with "CC:
> stable@...r.kernel.org" are automatically accepted into stable kernel
> series.
>
> If you can point efforts where painful backports of ext4 and xfs bug
> fixes into RHEL 6.x are making it back into 2.6.32.y, even though in
> some cases it takes tens of hours of engineering and QA efforts, we
> can talk.  But please note that I wasn't calling out Red Hat as being
> bad or evil by doing what they are doing; it is completely
> economically rational and allowed by the GPL rules for them to be
> doing what they are doing.  (Just as what Android has been doing with
> their constant forward porting of the Wakelocks API is completely
> within the GPL rules.)

And what _exactly_ is Red Hat (not) doing?  Red Hat isn't going crazy
backporting its upstream > 2.6.32 fixes to 2.6.32.y even when Red Hat
doesn't consume 2.6.32.y?  *gasp*

Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/