Re: [PATCH 3/4] UBI: Fastmap: Care about the protection queue

From: Tanya Brokhman
Date: Tue Oct 14 2014 - 09:36:04 EST


On 10/14/2014 4:02 PM, Artem Bityutskiy wrote:
On Tue, 2014-10-14 at 15:21 +0300, Tanya Brokhman wrote:
Hi Artem/Richard

I think your discussion here stopped being relevant to this specific
patch but went on to the fastmap feature design in general :)
This patch fixes a real bug in the current implementation of the
feature. What you're discussing requires a re-writing and re-design of
the feature. Perhaps this one can be merged and will be "fixed" later on
when you agree on how you would like FM to access WL data structures in
general?

First of all, "re-writing and re-design of the feature" is an
overstatement. So far this is on the "cleaning things up" side of the
spectrum, closer to the "re-factoring" area.

WRT "merge the fix now and improve later" - this is a good argument for
an "inside a company" discussion, where the primary TTM is the driving
factor.

For the community TTM is a good thing, but quality comes first.

Now, if this was about a regression, one could apply time pressure on
the maintainer. But we are talking about a problem which was there from
day 0.

It is completely normal for the maintainer to push back various
hot-fixes for the problem and request some reasonable re-factoring
first. This is what I do. This is very very usual thing in the Linux
community.

So far I did not ask anything huge and unreasonable, I think. Just
cleaner inter-subsystem APIs, less of the "fastmap uses the other
subsystems' internals" kind of things.

--
Artem.


Ok, accepted. It was just a suggestion. I'm all for quality coming first, even if you were asking for something "huge".

Thanks,
Tanya Brokhman
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/