> 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.
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.