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

[Prafulla Wadaskar]

> -----Original Message-----
> From: Holger Brunck [mailto:holger.brunck at keymile.com]
> Sent: 03 July 2012 19:13
> To: Prafulla Wadaskar
> Cc: u-boot at lists.denx.de; Valentin Longchamp;
> albert.u.boot at aribaud.net; Detlev Zundel
> Subject: Re: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
> km_kirkwood
> 
> On 07/03/2012 03:07 PM, Prafulla Wadaskar wrote:
> >>>>>>>
> >>>>>>> This patch makes sense to me since it since it shrinks overall
> >>>> code.
> >>>>>>> Doe not have dependency in patch series, can be accepted if
> >>>> outside
> >>>>>> the series.
> >>>>>>>
> >>>>>>
> >>>>>> again, but there are a lot of dependencies between 01-02 and
> 03-
> >> 04
> >>>>>> because all
> >>>>>> doing a lot in km_kirkwood.h.  So do you have any particular
> >>>>>> objections against
> >>>>>> the first two patches, beside your input for the kwbimage.cfg
> >> which
> >>>> I
> >>>>>> answered
> >>>>>> in a different mail?
> >>>>>
> >>>>> As I suggested earlier
> >>>>>
> >>>>> You may have patch series for the bugfixes/improvements to the
> >>>> currently supported code.
> >>>>>
> >>>>> You may have new board support as separate patch, if those have
> >>>> dependency, get it addressed first.
> >>>>>
> >>>>> As such I do not have any objection about longer patch series
> but
> >>>>> Generally having a long patch series requires longer time to be
> >> get
> >>>> pulled in.
> >>>>>
> >>>>
> >>>> so and when do you think to pull this in? AFAIK we are shortly
> >> before
> >>>> rc1. And I
> >>>> would like to  see this in, everything was published before the
> >> merge
> >>>> window was
> >>>> closed and we have reacted on every input you gave. But we can't
> >> react
> >>>> on inputs
> >>>> which are not clearly stated.
> >>>>
> >>>> So how do we proceed here to get this in for v2012.07? If I
> >> summarize
> >>>> the
> >>>> situation you don't have any particular objections against 01-08
> of
> >>>> this series.
> >>>> So should I resend these eight patches as a standalone serie to
> get
> >> at
> >>>> least
> >>>> these patches in?
> >>>
> >>> Yes, Please send the patch series for bug fix and improvements
> ONLY,
> >> I will pull them ASAP.
> >>>
> >>> The others we can converge soon.
> >>>
> >>
> >> But 01-08 are not only bugfixes there are also two new boards in
> these
> >> patches.
> >> So will you pull these eight patches in if I post them again
> without
> >> 09-14?
> >
> > Pls post bug fixes and improvement patches first those will be
> pulled faster.
> >
> This was already done from my side:
> http://lists.denx.de/pipermail/u-boot/2012-May/125219.html
> 
> Sorry Prafulla but I have admit that this whole discussion costs a lot
> of time
> which I do not have. We are moving in circles your last comment was
> already
> discussed several times e.g.:
> http://lists.denx.de/pipermail/u-boot/2012-June/126081.html

Dear Hogler

Do you think I should pull this patch series, I hope it applies cleanly on the recent master branch.
Please confirm.

> 
> So again you have no specific inputs of improvements for 01-08 right?
> All you
> rephrase are some general comments which are not very helpfull to
> improve our
> situation and to get our own board code into mainline.

Well.. we can keep discussing patches here until all the patches in the patch series gets acked.
This adds time/cost to the developer and reviewer too.
My old experience tells me that shorter is simpler and easier to accept.

I personally don't wish to hold any thing that sounds good to me.
The idea is how the development can be shared across the community.

So I had certain questions in my mind about your development for which I don't want any answers. You can treat them as feedback for your future development.

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?
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?
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.

We both have different thinking hats :-D
In your view, your code is important to get mainlined, may be you don't care other things.
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.
I might have done mistakes, I express grand SORRY for that :-(

I am always there to help everybody with my limited resources and time.

Regards...
Prafulla . . .