This is partly a communication problem

Posted Mar 6, 2011 23:59 UTC (Sun) by coriordan (guest, #7544)
In reply to: Commitment to Community(?) by ceplm
Parent article: Commitment to Open (Red Hat News)

> We are trying to make it difficult to *support* RHEL, not to develop Linux kernel.

No one's questioning that, AFAICT.

What the community is asking is: what's Red Hat's response to the complaints of kernel maintainers Maximilian Attems and Greg Kroah-Hartman?

No one's questioning Red Hat's motives, their contributions, or their right to impede the business of parasites. I'm not anti-Red Hat, and I don't think that posing the above question is an attack on Red Hat. It's just a valid question, but so far, there's no answer.

This is partly a communication problem

Posted Mar 7, 2011 0:36 UTC (Mon) by msnitzer (subscriber, #57232) [Link] (1 responses)

Have you seen this answer?

This is partly a communication problem

Posted Mar 8, 2011 14:29 UTC (Tue) by coriordan (guest, #7544) [Link]

Your post makes the points that:
* RH pushes stuff upstream
* Porting patches from RH's kernel to stable is inherently difficult

I think the kernel developers already know this. They didn't question or complain about either of these things, they complained about the new Big Kernel Patch.

A sample good answer from RH would be "Ok, in future we'll set up a phone call between the relevant person here and the stable kernel maintainer before each release".

I'm not trying to embarrass RH by asking this question. On the contrary, I see them often as the role model for free software participation. So when they do something which shouldn't be copied by others, I think the question is worth asking: can this problem be fixed?

If this story was about Oracle, I wouldn't bother hoping for a fix.

This is partly a communication problem

Posted Mar 7, 2011 3:49 UTC (Mon) by ricwheeler (subscriber, #4980) [Link] (8 responses)

RHEL6 is *not* 2.6.32 stable based and never has been.

If you are a developer with a distro based on a stable series, you have to do your homework. When another upstream developer flags a patch as stable material, you need to understand if that patch is applicable to your kernel. That patch might - or might not - apply. It might be totally irrelevant.

Should Red Hat developers backport their fixes for other developers' branches? Why just .32 stable which Oracle and SLES use? Why not backport to the embedded stable series as well?

This is partly a communication problem

Posted Mar 7, 2011 4:50 UTC (Mon) by foom (subscriber, #14868) [Link] (4 responses)

I think you're being disingenuous. RHEL6 is 2.6.32-based. So it seems reasonable for maintainers of other distros based on 2.6.32 (like Maximilian for Debian, or GregKH for upstream-stable) to want be able to check RedHat's kernel source for patches which might be applicable to their kernels as well.

RedHat of course doesn't need to themselves backport fixes to other people's kernels (including 2.6.32-stable)...now, ideally, they *would* also participate in upstream stable branch maintenance themselves for whatever kernel they've based on (everyone else seems to be doing so...), but, it's okay if they don't. However, it's *not fine* to intentionally make it difficult for others to do that work. That's incredibly lame.

I hadn't seen this link referenced here before, so, here it is for anyone else that missed it:
http://lwn.net/Articles/430600/

This is partly a communication problem

Posted Mar 7, 2011 11:27 UTC (Mon) by ricwheeler (subscriber, #4980) [Link] (3 responses)

Strange, as someone directly involved in developing RHEL6, I thought that I would know more about how we did than you did.

Here are the facts:

RHEL6 is based on Fedora which was our point of forking when it had a 2.6.32 based kernel. Note I did not say 2.6.32 stable.

After forking from mainline, we continued to work on tip of upstream actively during the alpha and beta phases on key subsystems.

Our developers would post to upstream tip, flag patches for stable and provide a backport to RHEL6.

Before RHEL6 went out the door, many subsystems in the kernel were 2.6.34 or 2.6.35 based. At this point, some subsystems are much closer to 2.6.37 (specifically things like file systems that we have a very large and active upstream developer pool).

This is a key misconception - RHEL6 is not a 32 stable series product and never has been.

This is partly a communication problem

Posted Mar 7, 2011 13:09 UTC (Mon) by foom (subscriber, #14868) [Link] (1 responses)

> Strange, as someone directly involved in developing RHEL6, I thought that I would know more about how we did than you did.

I'm sure you do. However, you might note that *I* did not say it was 2.6.32-stable based either, only that it was 2.6.32 based...

> Our developers would post to upstream tip, flag patches for stable and provide a backport to RHEL6.

So you're saying Maximilian didn't actually need to look at the RHEL6 source at all, because all of the bugfix patches RHEL6's kernel includes have already been flagged for backport to upstream stable branches? I get the impression that he wouldn't agree with that statement, but for myself, I have no information for or against.

If that is true, that would certainly make it *much* less of a problem that it's difficult for other people to do the work of checking out the patches.

This is partly a communication problem

Posted Mar 8, 2011 11:33 UTC (Tue) by pbonzini (subscriber, #60935) [Link]

> So you're saying Maximilian didn't actually need to look at the RHEL6
> source at all, because all of the bugfix patches RHEL6's kernel includes
> have already been flagged for backport to upstream stable branches?

Only he can answer, but my hypothesis is that

- he spelunked the RHEL6 changelog to distinguish: 1) features, 2) bugfixes which were in stable, 3) bugfixes which were not in stable because the original author forgot to CC stable@kernel.org.

- he focused on the third group here, which may have included patches from both RH and non-RH authors. RH is _not_ actively hiding their stuff from stable@kernel.org.

- he then used the summary of the patches in the changelog to identify upstream commits

- he backported those

Assuming he selected patches whose backports were relatively easy, no, he didn't need to look at the RHEL6 source at all.

To be fair, he would have probably benefited from the full commit messages; these are part of the patch files so they are also not included in RHEL6.

This is partly a communication problem

Posted Mar 8, 2011 1:42 UTC (Tue) by riel (subscriber, #3142) [Link]

Several subsystems in the RHEL 6 kernel have been upgraded to be close to 2.6.33, 2.6.34 or newer. Fixes to that code may simply not apply to the 2.6.32-stable codebase.

People who use 2.6.32-stable may need to do their own backports, since many of ours won't apply anyway.

This is partly a communication problem

Posted Mar 7, 2011 13:54 UTC (Mon) by lmb (subscriber, #39048) [Link] (2 responses)

Hi Ric, yes, well, there is a point to that. But it is also common for partners and customers to report "works with kernel XY", and now one of the parties has made it much more difficult for other maintainers to look up why - while the others still publish their broken out series.

While I personally wish the whole enterprise distribution approach would go away (and people would instead pay us for supporting them on latest upstream - hey, a boy can dream), I also know that there's a pretty good cooperation between the engineering teams. I hope that is not affected.

This is partly a communication problem

Posted Mar 7, 2011 14:31 UTC (Mon) by ricwheeler (subscriber, #4980) [Link] (1 responses)

I don't see any reason that work upstream is impacted by how we package patches against the RHEL6 tree.

In addition, I fully expect our kernel team to continue to help any one on any distro understand, debug, etc just like we always do.

This is partly a communication problem

Posted Mar 7, 2011 20:30 UTC (Mon) by dlang (guest, #313) [Link]

how long can the engineers on the kernel team continue to help others when management is explicitly trying to make it harder for those same others?