| |||||||||||||
This is partly a communication problemThis is partly a communication problemPosted Mar 7, 2011 4:50 UTC (Mon) by foom (subscriber, #14868)In reply to: This is partly a communication problem by ricwheeler Parent article: Commitment to Open (Red Hat News)
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:
(Log in to post comments)
This is partly a communication problem Posted Mar 7, 2011 11:27 UTC (Mon) by ricwheeler (subscriber, #4980) [Link]
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]
> 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.
|
|||||||||||||