[U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Wolfgang Denk <wd@denx.de>]

Dear Prafulla,

In message <F766E4F80769BD478052FB6533FA745D1A2FE3028D@SC-VEXCH4.marvell.com> you wrote:
> 
> Do you think I should pull this patch series, I hope it applies cleanly on the recent master branch.
> Please confirm.

I have to admit that I neither reviewed the patches in question, nor
did I follow the whole thread of communication in this patch series.
But the general rule is that if there are no strong argumentents
against a patch (like a clear NAK or a specific request for changes)
we will apply it.

> 1. Why do you modify the board parameters so frequently? I see
> several patches for these, cant you freeze all this well before
> posting board support patch?

Actually it's this question which triggered my reply.  From a
developer's point of view it makes a lot of sense to push patches
upstream as soon as possible, to have at least the major bunch of code
maintained with the mainline source tree, even if board configuration
and other board specific code still needs to be changed.

We all complain frequently aboutquestions for obsolete code in some
out-of-tree ports, so we should strongly support such early patch
submissions, and not discourage it.

And frankly, as long as its strictly board specific code only, we
don't even have to care if it works.  

> 2. Why do you use your own keymile-common.h, can't you migrate to
> use mv_common.h which mainly created for the same purpose?

Probably for the same reasons: patches get submitted early, when
configurationhas not stabilized yet, and it's much easier for all
involved parties to change some board or vendor specific file instead
of one that gets used for the whole architecture.

> 3. When you support any generic peripheral can't you think of generic use case?
> 
> >
> > We try to stick to every rule which is valid for u-boot development.
> > But we
> > can't stick to rules which are not clearly stated.
> 
> You better can have your own world, and maintain the code the way
> you want, not necessarily you need u-boot for this.

I don't understand what you mean here.  As a custodian you have a
responsibility to support a submitter.  Yes, this may include that you
reject incorrect code, maybe even if it's only violating the Coing
Style.  But from what I've seen so far I think Keymile really strives
hard to play by the rules.

If there are violations of any documented rules, then please say so
clearly, and NAK the patch.  If there are other things that should be
fixed, where rules are not clear, then we should discuss the problem,
the way how we would like to see this fixed, and document these new
rules for future cases.

> In your view, your code is important to get mainlined, may be you
> don't care other things.

In our view it is also important to get this code mainlined, as it is
always important to help users to have their submissions mainlined.
This is one of the major responsibilities of us maintainers to the
community.  If we were free to ignore the users, we would probably
quickly be free of any community, too.

> In my view, how any support can be added in simpler, shorter,
> reusable, cleaner way in-sync with development strategy. I am just
> trying to follow this.

The question is how many iterations really make sense.  In this case
there appear to have been too many already.  If there are no clear,
hard deficiencies in the code that need fixing, then I think we have
to put an end to such dicussions earlier.

> I might have done mistakes, I express grand SORRY for that :-(
> 
> I am always there to help everybody with my limited resources and time.

We all apprecate your efforts. Please don't misunderstand me, I don't
intend to interfere with your job as a custodian here. You just
happen to trigger my message whichis actually directed to all
custodians: please help to get patches accepted, for the sake of
encouraging users to submit their code. If we frighten off such users,
all sides lose - the users, and us.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As far as the laws of mathematics refer to reality, they are not cer-
tain, and as far as they are certain, they do not refer  to  reality.
                                                   -- Albert Einstein