Dropping architectures just for the sake of bisectability does more
harm than good.
We never dropped architecture support due to a rewrite in course of
the whole preempt-rt series. We never dropped architecture support
when we made parts of the code ready for upstream and made it
bisectable.
Keeping the architecture ports even in a maybe disfunctional state in
the queue is important as we move them along and make the obvious
changes to them so anyone interested to bring them up to date has not
to start from scratch again, which is a major PITA (we just did one
from scratch)
Yes, and if you care to look at the code which was merged into
mainline, then you might notice that it was always made
bisectable. Usually it was rewritten pretty much as well.
With half of the functionality dropped, renames along the line so it
can not be verified whether it ends up to be the same code as it was
before. If you really want to make it bisectable then apply the
necessary rename patches to the queue first, make sure that it does
not result in a code change and then refactor the whole thing.
We have been there before. kernel development does not follow the "we
want _now_" principle at all. Have you ever tried to yell at Linus "we
want XYZ _now_" ? If you decide to try it, please keep me on CC - I
want to enjoy the show.
Sure, we are happy to trade a queue which has major updates of code
close to mainline integration and has preserved the existing
architecture support for some bisectable artifact.
We went through this kind of discussion several times in the past and
you still seem to believe that you can impose your POV on project
maintainers.
Again, that's not the way it works.
Nobody will object the refactoring of the queue when it is done in a
cooperative way. By creating a fact and trying to enforce it by any
means you'll only reap controversy and attention, not any real
progress.
Exactly, for the majority of problems with preempt-rt, reporting the
bug and waiting for the person who is able to decode it is the only
choice. The hard to decode problems like subtle races are not
decodable by bisection.
Bisectable problems are pretty rare, because most of the problems are
with PREEMPT_RT, which is a disruptive new feature that only gets
activated late in the queue.
Again, we are of course not opposed to a cooperative effort to make
the queue fully bisectable - as long as it has no drawbacks. That
means gradual steps, which is not rocket science.
Thanks,
tglx
--
