It is only important for merging to a new tree, nothing more here. A
bisectable tree is important to make sure all new enhancements can be
tracked to see which feature broke the kernel. The reason we want it
bisectable in Linux, is when a bug appears we can do a binary search
(git-bisect) to find the culprit.
Doing this with the -rt patch doesn't solve that key issue. The reason why
is that new enhancements to the -rt patch happen in small patches. In
fact, by folding in a bunch of patches, we have just lost that ability!
The -rt patch has a bunch of features that it adds to the kernel. Having
the -rt patch queue bisectable doesn't find the bug that was introduced by
a new change to a patch deep in the queue (caused by folding). Ideally,
and I've done this to an extent, is to have each change as a separate
patch. This can help us find which change caused a bug.
Having the -rt patch queue as a bisectable queue (all 350+ patches) ONLY
HELPS IN FORWARD PORTING TO ANOTHER VERSION OF LINUX! That said, it is
usually the maintainers that do this. I have certain points in the queue
that I make sure can compile and test a new feature, to make sure
something didn't break in the port. I don't need each patch of that
feature bisectable, because the feature in the whole may be broken by
something that happened in upstream.
I told you what to do, and so did Thomas. It's not rocket science, and it
is something I would do to make sure as well. Hell, Ingo and Thomas did
this for the x86 merge which was 10 times more complex than making the -rt
queue bisectable.
This is what you should have done.
1) if you needed to make changes to the code (your renaming), do that at
the end with extra patches.
2) save that final result.
3) go through and modify all the patches to your hearts content, to get a
bisectable queue out the door.
4) compare the end result with the result from step 2.
What's so fscking difficult about the above?????
If Ingo and Thomas told Linus to just accept the x86 merge without doing
this exact thing, and then told Linus that it is his job as maintainer to
review the changes to make sure they are correct, there would have not
been any x86 merge today. In fact, if they had the nerve to do that, they
would have lost all respect in the Linux community.
Guess what? You're doing exactly what I said Ingo and Thomas DID NOT DO!
The patch queue is 350+ patches. It is not up to me to go through and sort
out exactly what you did. That would take me a week to look at each
individual patch and know what was in your head. Sorry, that is your
responsibilty to help out here.
As I said, the paradigm for the -rt patch is completely different. Having
a bisectable patch queue to go into Linux is to find out where a bug was
introduced. Linux evolves in a simple straight time order of events. This
is not true with the -rt patch. To do this, I would keep all patches
unchanged in the tree, and only add new patches at the end, and never fold
anything. We do this to a point, and after a few releases, we start to
fold patches in that we feel are stable.
Again, having a bisectable -rt tree is to help with forward porting only.
And it doesn't even need to be fully bisectable. Just needs to have
certain points to verify. Usually a bug is introduced by something that
changed in upstream that gets broken not by one patch in the -rt tree, but
by the new concept that the -rt tree introduces. For example, something
might break because we have interrupts as threads. This isn't found by a
bisectable tree, its found by turning off different configuration options
of the -rt patch.
I did not default reject it. I told you what we wanted, and you made
absolutely no effort in complying. So in return, I made absolutely no
effort in looking at what you did.
Because you refuse to listen to what we say, and you keep pandering that
your changes are so damn important that we need to forget all our own
principles to listen to the word of Daniel.
-- Steve
--
