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

[Henning Schild <henning.schild@siemens.com>]

Am Tue, 22 Aug 2017 17:31:02 +0200
schrieb 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.

Ok, understood. I think using issues as reminder list might shine the
wrong light on the project, but that is a personal feeling.

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

We can proceed in this way or stick to the original plan. Or use one
where both sides modify the patches, depending on the change that needs
to be made.
But if anyone substancially changes a patch it has to be reviewed
again. Or at least end up in "the official" next branch where it will
sit for a few days for everyone to look at.

Henning
 
> With kind regards,
> Baurzhan.
>