Messages in this thread | | | Date | Wed, 30 Jan 2002 15:58:37 -0600 | From | Eli Carter <> | Subject | Re: A modest proposal -- We need a patch penguin |
| |
Linus Torvalds wrote: [snip] > Now, after those arguments, I'll just finish off with saying that I > actually agree with you to some degree - as I already said in private > email to Larry, I would definitely also want to have a way of stopping > back-merging at some point. In particular, when I'd tag a relase (ie > something like Linux-2.5.3, I would potentially also want to set a > "backmerge marker tag" which basically tells the backmerge logic that it's > not worth it to try to backmerge past that version tag. > > That would decrease the chance of confusion considerably, and it would > also avoid the exponential complexity problem. Let's face it, exponential > algorithms can be really useful, but you do want to have some way of > making sure that the bad behaviour never happens in practice. A way of > limiting the set of changelogs to be considered for backmerging not only > means that humans don't get as confused, the computer also won't have to > work insanely to try to go back to Linux version 0.01 if a small patch > happened to apply all the way back. > > Linus [and earlier...] > However, you are obviously correct that any changes are inherently > dependent on the context those changes are in. And there are multiple > contexts.
What about the design context?
I'm a bit concerned about the design-level inter-dependencies of changesets that don't result in source-level dependencies.
Hypothetical situation: Changeset adds driver for device Q. Now, let's further suppose that in 2.5.x we have perfect modularity for drivers and at that time Q is added... we just add a directory, linux/drivers/Qdrv. It won't conflict with 2.5, 2.4.x, 2.2.x, etc.. However, because 2.2.x does not have the hooks necesary to see it, Q won't work on those kernels. There is a design-level dependency in changeset q.
This would be indirectly addressed with the 'backmerg marker tag', but I have a nagging doubt.
Maybe a better example: What about changing a global variable (say, from 'events' to 'global_events')? You change it in the global place, yielding a changeset. Later, the individual users change the name. But if an individual user has seen very little change in the time before the global_events change (and the global location has been changing a lot), that patchset could backmerge beyond the global change.
Say 'f' was the global change, and 'g' was an individual change. Backmerge could yield:
a -> b -> c -> f
-> d
-> e -> g
even though 'g' really depends on 'f'.
Thoughts?
Eli --------------------. Real Users find the one combination of bizarre Eli Carter \ input values that shuts down the system for days. eli.carter(a)inet.com `------------------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |