[U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support

[Jagan Teki]

On Fri, Apr 26, 2019 at 11:07 PM Paul Kocialkowski
<paul.kocialkowski at bootlin.com> wrote:
>
> Hi,
>
> Le vendredi 26 avril 2019 à 22:51 +0530, Jagan Teki a écrit :
> > On Fri, Apr 26, 2019 at 10:38 PM Paul Kocialkowski
> > <paul.kocialkowski at bootlin.com> wrote:
> > > Hi,
> > >
> > > Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > > > > boards are using this file and next series rest of the boards are
> > > > > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > > > > understand.
> > > > > > >
> > > > > > > Yes, what you are describing is exactly the issue. It does not make
> > > > > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > > > > devices that use this file *before* switching existing devices to the
> > > > > > > new common u-boot dtsi for rk3399 in the same series.
> > > > > >
> > > > > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > > > > patch says it is an initial one and it is bit hard to add all at once.
> > > > > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > > > > unaffected to any of the existing dts files.
> > > > >
> > > > > Again, it's not a technical issue. Your proposal works and has no
> > > > > technical issue. The issue is in how the commits are grouped together.
> > > > > Patch series need to make logical sense. One patch series should
> > > > > accomplish one change, and each patch represents a step of that change.
> > > >
> > > > It's about how you think. say if I wouldn't send the binman, I'm sure
> > > > this kind of discussion may not happen. In first mail you said
> > > > "something broken and how it can repair next" that indeed doesn't make
> > > > any sense of without understanding the whole series of changes.
> > >
> > > One part to that is that I had misunderstood a few things, but I really
> > > should not have to look at each patch before I can have an idea of what
> > > the series does. Your series is called "rockchip: Add new rk3399
> > > boards" and with the v3.1 change you made, the title is no longer true.
> > > You are doing that + introducing a new rk3399 u-boot dtsi without
> > > switching existing boards to it before adding new ones.
> > >
> > > From that moment, you needed to split your changes into two series.
> > > Instead of that, you made another series with mostly unrelated changes
> > > where you included an unrelated commit adding the pre-reloc entries to
> > > the dtsi created in the previous series.
> > >
> > > That's an issue for communication with the community.
> > >
> > > > Any new changes would come up with initial version, that what we
> > > > usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> > > > developers are using the same is adding one after another.
> > >
> > > But you already have boards in the tree that needs the tree. You can
> > > make individual commits for switching boards to the new dtsi, but you
> > > need to do that in the same series as introducing the dtsi if you are
> > > submitting both things at the same time. If you want to have them
> > > merged separately, then you can send device dtsi patches individually
> > > for that, but not as part of another unrelated series.
> > >
> > > > > This is how upstream contributions work, and it's a powerful way to
> > > > > allow both efficient code review and good code quality. We want to keep
> > > > > things as simple, explicit and well-described as possible, so that
> > > > > things are easy for reviewers and as many people as possible can
> > > > > understand the issue and share their thoughts about it.
> > > >
> > > > Yes, we adopt these principles and that what we are really working.
> > > >
> > > > > It is all part of communication with others as part of a community.
> > > > > It is definitely an implicit rule that is not written down somewhere
> > > > > precisely, but that's the social contract between developers that work
> > > > > on a common software project.
> > > > >
> > > > > In that, contributing to upstream is different than baseline tech
> > > > > company standards, because you have to take extra steps to describe
> > > > > your work and explain it to others. You must make sure you give them
> > > > > all the comfort they need to painlessly understand what you did.
> > > >
> > > > I hope all my communication was relevant to the topics, I can even
> > > > given the example how things were moved.
> > >
> > > Clearly there was a major communication issue between us. You only
> > > answered on technical topics and never about how your patch series is
> > > organized and what logical changes you are making.
> > >
> > > To be honest with you, I feel like we have a general communication
> > > issue where you only seem to focus on technical aspects, when the
> > > issues are about the meta-data of the changes such as commit messages,
> > > code comments and how changes are organized together.
> >
> > No one is better in all aspects, and things were improving no one cam
> > make global statements like this though he can find something gaps on
> > on previous one. You would better suggest on the commit where it
> > confused can make me better understanding.
>
> I am making such a global statement because I've had this issue with
> you a few times before already, and from what I could see about sunxi-
> related discussions, it seems that others have had similar issues
> before too. Each time, it feels like you are not discussing the issue
> and answering on mostly-unrelated technical topics, exactly like it's
> happening now.
>
> Now this is really nothing personal against you, I have no interest in
> pointing out things that need to be worked on in the work you submit in
> order to make you feel bad or inferior. But at this point, I feel like
> you are not understanding the global issue so I am bringing the
> discussion to more general conclusions, since we are talking about
> communication issues more generally.
>
> Everyone is trying to improve and it's perfectly fine to have flaws.
> For that matter, the situation was already reversed a few times when
> you reviewed some of my sunxi patches saying that the commit log was
> unclear, and I gladly accepted the criticism to make a better next
> revision. I also want to add that you make significant important
> contributions to lots of projects I really care about. This thread is a
> perfect example of that too, since I plan on using a RK3399 boards you
> are introducing for my personal use. So I am more than happy to see you
> do all that hard work and I truly value your contributions.
>
> Really, I'm mostly trying to help here and collaborate towards
> resolving the situation.

Thanks.

>
> So could you please send 3 distinct series that deal with each one of
> the aspects from the list that follows?

Just now I sent v5, which would resolve what you are thinking of,
please have a look.