Dear Prafulla, In message <f766e4f80769bd478052fb6533fa745d1a2fe30...@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: w...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot