> On the one hand, that's not necessarily true. If you're working for a
> distribution but work closely with your upstream, you might work "in" your
> Debian source or SRPM environment, but test for the existence of a
> user-reported bug in the upstream code first, and if it is present there, > patch it there before porting it back down to your own distro.
> Needless to say, this pattern is often done in reverse, but I'm sure a lot > of upstreams would like to see more instances of the above.
> And that's exactly why Red Hat's move here has some kernel hackers (Greg
> K-H at least) wincing.
If I understand correctly, you want to cherry-pick patches from 2.6.32-el6 to 2.6.32-stable. So you're treating here "2.6.32-stable" as the downstream and "2.6.32-el6" as the upstream. Nobody disputes here that the monolithic kernel SRPM is making things harder. However, note that you are _not_ making modifications to RHEL kernel. You'd like the RHEL kernel to be distributed in your preferred form "for modification of something else", and that's not a right that the GPL grants you.