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/