On Mon, 2008-05-05 at 23:01 +0200, Thomas Gleixner wrote:
quoted text
> Dan
> 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)

In open source code never dies. So I'm not sure where this "From
scratch" stuff is coming from .. 

I've done ports from scratch and it's not that bad.. Not sure what your
porting too.. It would also be a lot easier to do an arch port piece by
piece under a bisectable tree.

I think dropping ports (temporarily) is perfectly reasonable. There is
no reason to hamper forward development just to keep old architecture
ports in the tree.

quoted text
> 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.

I just review code and boot it in various ways. I don't think binary
compatibility is needed for this. For most code that exists, and most
cases in open source it's not needed either.

quoted text
> 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.

Kernel development is "What is available now?" not what is avaiable in
the future.

If you want to reject code you better have a reason other than "We're
going to make some new code for that (some time in the future) sorry."

I'd like to hear Linus come out and say, "Sorry Thomas we can't include
your HRT cause we're getting a newer HRT in three years, so sorry about
that."

I'm not the one that suffers if Steven doesn't include some sort of
bisect change, the users suffer, development suffers.

quoted text
> 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. 

Sure it is.. When a maintainer makes a mistake I better speak up, or
they're gonna make a mess of things .. That's a huge chunk of the
process.

quoted text
> 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.

I don't agree with that .. We don't have bisection you can't even back
up the claim .. Had bisection been an option I'm sure it would have been
used.

Daniel

--
unsubscribe notice
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/