2 ms·

Not to make modifications, but, as far as I understand, to merge/integrate patches to the vanilla kernel from other sources.

by hasenj 16y ago

rbanffy 16y ago
Unless they start renaming files, interfaces, functions and structures for no reason, it's really trivial to start with tree A and get a set of differences between it and tree B. Almost a decade ago, I wrote some utilities that did exactly that, for merging and finding commonalities between the many (almost a dozen) different versions of the C programs that ran on our electronic voting systems.
- davidw 16y ago
  > it's really trivial to start with tree A and get a set of differences between it and tree B. Ok, now figure out which patch each of those differences belongs to, and for extra credit figure out in which order they were applied. The point is not that it's impossible or something, it's that it now takes up extra time to find out information that they're basically hiding.
  - rbanffy 16y ago
    > now figure out which patch each of those differences belongs to Why would I have to do that? And don't forget we not only have the current tarball, but we can analyze every release for differences, capturing some history with it. Reconstructing each original patch may not be possible (it's an interesting problem), but reconstructing a set of distinct patches is. Humans would then be better at assigning meaning to them, even if it means calling Red Hat's support line and paying for the answer.
    - davidw 16y ago
      > Why would I have to do that? Come on, I'm sure you can think of a reason or two why you might want to enable or disable specific patches.
      - rbanffy 16y ago
        There is a difference between disabling a Red Hat patch and a group of changes between a set of files. Separating the large diffsets by fileset alone may provide good cues as to what they do. You can always pay Red Hat to have their patches.

Not to make modifications, but, as far as I understand, to merge/integrate patches to the vanilla kernel from other sources.

by hasenj 16y ago

Not to make modifications, but, as far as I understand, to merge/integrate patches to the vanilla kernel from other sources.

rbanffy 16y ago

Unless they start renaming files, interfaces, functions and structures for no reason, it's really trivial to start with tree A and get a set of differences between it and tree B. Almost a decade ago, I wrote some utilities that did exactly that, for merging and finding commonalities between the many (almost a dozen) different versions of the C programs that ran on our electronic voting systems.

davidw 16y ago
> it's really trivial to start with tree A and get a set of differences between it and tree B. Ok, now figure out which patch each of those differences belongs to, and for extra credit figure out in which order they were applied. The point is not that it's impossible or something, it's that it now takes up extra time to find out information that they're basically hiding.
- rbanffy 16y ago
  > now figure out which patch each of those differences belongs to Why would I have to do that? And don't forget we not only have the current tarball, but we can analyze every release for differences, capturing some history with it. Reconstructing each original patch may not be possible (it's an interesting problem), but reconstructing a set of distinct patches is. Humans would then be better at assigning meaning to them, even if it means calling Red Hat's support line and paying for the answer.
  - davidw 16y ago
    > Why would I have to do that? Come on, I'm sure you can think of a reason or two why you might want to enable or disable specific patches.
    - rbanffy 16y ago
      There is a difference between disabling a Red Hat patch and a group of changes between a set of files. Separating the large diffsets by fileset alone may provide good cues as to what they do. You can always pay Red Hat to have their patches.