Re: [PATCH 0-10 of 16 v2 4/8] meta: conf: use bitbake.conf from bitbake and apply local changes

[Baurzhan Ismagulov <ibr@radix50.net>]

On Tue, Aug 22, 2017 at 02:45:28PM +0200, Henning Schild wrote:
> We agreed that he would change my patches to save me the time to rebase
> and change them. I asked him to add his signed-off to all patches he
> actually modifies. 
> After that offer i did not hear back about remaining issues, so i
> assumed they all got fixed on your side. And now "my commits" are the
> cause for issues ... If you see the issue coming you should bring it up
> in the review and not after applying the patch.
> 
> I further assumed that any such patch would naturally be published for
> review again, which did not happen or at least the comments where
> ignored.

Oh, please let me know whether I understand you correctly:

You didn't like the way how I recently handled your patches, because you want
to provide complete, high-quality code, and:

1. Issues related to a commit may lead to doubt regarding the commit quality.

2. You don't necessarily agree with my or Alex's changes.


If this is the case, I agree that switching back to the classic workflow
would be the best way to go. Still, let me comment on the points above.

1. I use issues as reminders to do something later without blocking code that
   has value, especially right now, when we process the patch backlog. E.g., I
   don't want to block isar-bitbake.conf till we enhance upstream bitbake.
   Similarly, the documentation should not be forgotten -- this is the only
   reason for that, apply and move forward.

2. Changing patches (sometimes substantially) before applying is common
   practice in e.g. Linux kernel. Again, we did that with the intention to
   speed up the process. I see that our attempt produced the opposite results.


Now that we haven't processed all your patches, I'd suggest the following:

* You rebase your changes on master and send them to the list.

* We provide feedback and don't change your patches, even if it costs one or
  another round-trip.

* If we all agree on a particular patch, it goes in, completely and verbatim.

Could we proceed in this way, or do you have an alternative suggestion?


With kind regards,
Baurzhan.