On Fri, Apr 26, 2019 at 11:07 PM Paul Kocialkowski <paul.kocialkowski@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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. _______________________________________________ Linux-rockchip mailing list Linux-rockchip@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-rockchip
