Quoting Jon Peatfield <J.S.Peatfield@xxxxxxxxxxxxxxx>:
Maybe now would be a good time to start thinking about moving (in a few months maybe) to a kernel tree based on 2.4.26/27pre just to reduce the total number of overlapping patches.
Unless we find that patch conflicts are causing build/maintenance problems for us, I don't see this as a positive move.
Now that 2.4 is firmly in "maintenance mode" there won't be any new features added so it should be possible to remove a great number of the existing patches just by using a more modern starting point.
While new features won't be added now, have they already been added between our starting point and now? If so, it kind of goes against our policy, unless it facilitates our continued support of the kernel.
Of course without understanding what _all_ of the patches are doing it is always a bit risky to decide which would still need to stay or be changed to be relevant against 2.4.26/27...
Sounds like maybe we don't need to take that risk...
So, unless we have problems with conflicting patches, I'd say stay with what we have.
If we go newer than RHEL 3, then our job becomes tougher as we can't take advantage of Red Hat's patches. Staying with our base, or moving only to the RHEL 3 version, gives us 3 years of using RHEL as an aide to our patches. Going newer means we would be on our own much more often...
-- Eric Rostetter
-- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
