Yes, and even if you were able to do so, there is still the problem of
testing against the version that Linus applies the patch to (which as
you said earlier, is a moving target). I guess one solution would be
to have the tool Linus uses (or should use:-) also do a test, and if
it fails, to bounce it. That would be done against Linus' working
tree.
However, that would reduce Linus' flexibility in applying a series of
patches which involves global API changes. Hm. Perhaps an option so
that Linus can accept a patch if he knows it's part of a global API
change.
Another alternative, which has been raised before, is Linus' patch
queue is made public. As I understand it, Linus files pending patches
into a special folder, and then later feeds that folder, en-masse,
into patch(1), and a release/pre-patch is born. That patch queue could
be distributed using the kernel.org mirror system. This would be a
generally useful thing, and with automated regression testing, reduces
the window for merge errors.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/