All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Kacur <jkacur@redhat.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>,
	david@lang.hm, linux-kernel@vger.kernel.org
Subject: Re: XFS problem in 2.6.32
Date: Wed, 8 Jun 2011 10:00:39 +0200	[thread overview]
Message-ID: <BANLkTim3GuppJ4=VHa0BgNV1d4nQjWUcbg@mail.gmail.com> (raw)
In-Reply-To: <C4F797E7-3B2F-4BAD-BF69-2182DEA775A5@mit.edu>

On Wed, Jun 8, 2011 at 5:28 AM, Theodore Tso <tytso@mit.edu> wrote:
>
> On Jun 7, 2011, at 5:57 PM, Stefan Priebe - Profihost AG wrote:
>
>>> whoever the maintainer of the -stable/-longterm tree is (be it an
>>> individual or a team employeed by some comapny) then looks at the patch
>>> and considers backporting it (if it's too hard, or to intrusive, they
>>> may decide not to).
>> So i have to contact Greg Kohan from SUSE directly?
>
> Only if you can identity a specific patch you want backported to 2.6.32.
>
> It's not the responsibility of the long-term stable tree maintainer to go looking through potentially tens of thousands of commits to find the one that should be backported.  And if the code has changed too much since .2.6.32, and requires detailed reworking before the patch can get integrated into 2.6.32, then a subsystem developer will have to do that work.
>
>>
>>> the idea of the lonterm kernels is that organizations need to maintain a
>>> kernel for a long time due to commitments that they have made (Debian
>>> doesn't want to change the kernel it ships in a stable version, RedHat
>>> doesn't want to change the kernel version in a RHEL release, etc), and
>>> so they publicly announce this so that anyone else wanting to use the
>>> same kernel version can share in the work (and therefor everyone can
>>> benifit from each other's work)
>> That was what i thoght. So a bug like this should get fixed right? Otherwise this makes no sense. Sadly Redhat has ported the fix back in his RHEL 6 2.6.32 kernel but they haven't send the patch to stable / vanilla team.
>
> Not all distributions will participate in the maintenance stable tree.  Red Hat for example is probably worried about people  (specifically, Oracle) taking their kernel expertise "for free" and bidding it against them.  So it doesn't surprise me that they aren't submitting patches to the stable tree.  After all, they would like you to purchase a support contract if you want to get high quality, supported kernel.   Why should they give that work away for free?  After all, their salaried developers have to get paid somehow.  Others will contribute work in the hopes that other people will also contribute fixes back, but of course nothing forces Red Hat to do this.
>
> The thing that you have to understand that this is all a volunteer effort, and a few of your messages sound like you are expecting people to do the work for you.   It doesn't work that way.  If you ask nicely, maybe one of the XFS developers will help you.  But please don't expect free support.  That will just annoy people.
>

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, - they are quite active in the
stable effort.

wget http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.38.8
grep Author ChangeLog-2.6.38.8 | grep -i redhat | wc -l
9

grep Author ChangeLog-2.6.38.8 | grep -i suse | wc -l
10

grep Author ChangeLog-2.6.38.8 | grep -i canonical | wc -l
5

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.
Don't know if lwn has stable stats.

Thanks

John

  parent reply	other threads:[~2011-06-08  8:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-07 12:46 XFS problem in 2.6.32 Stefan Priebe - Profihost AG
2011-06-07 13:36 ` Theodore Tso
2011-06-07 13:49   ` Stefan Priebe - Profihost AG
2011-06-07 19:45     ` david
2011-06-07 21:57       ` Stefan Priebe - Profihost AG
2011-06-07 22:05         ` david
2011-06-08  3:28         ` Theodore Tso
2011-06-08  7:05           ` Stefan Priebe - Profihost AG
2011-06-08  8:00           ` John Kacur [this message]
2011-06-08 13:38             ` Ted Ts'o
2011-06-08 14:16               ` Mike Snitzer
2011-06-08 18:50                 ` Ted Ts'o
2011-06-08 21:01                   ` Christoph Hellwig
2011-06-08  9:03           ` Alan Cox
2011-06-08 13:30           ` Steven Rostedt
2011-06-09  2:57             ` Dave Chinner
2011-06-09  7:22               ` Stefan Priebe - Profihost AG

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTim3GuppJ4=VHa0BgNV1d4nQjWUcbg@mail.gmail.com' \
    --to=jkacur@redhat.com \
    --cc=david@lang.hm \
    --cc=linux-kernel@vger.kernel.org \
    --cc=s.priebe@profihost.ag \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.