From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6450015460633083904 X-Received: by 10.46.64.142 with SMTP id r14mr9463lje.16.1503428145673; Tue, 22 Aug 2017 11:55:45 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.25.76.9 with SMTP id z9ls806517lfa.8.gmail; Tue, 22 Aug 2017 11:55:45 -0700 (PDT) X-Received: by 10.46.88.26 with SMTP id m26mr7771ljb.32.1503428145052; Tue, 22 Aug 2017 11:55:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1503428145; cv=none; d=google.com; s=arc-20160816; b=w5c3/p3r7CND1LNfmlA1iz4d5hoisrNWHEGUC2I+yK3RsbZ551iXByMKl+mRdFJH4M b/hjSd5Na8HXPwlWvhyaSw8BsD1s4mQMlVCK22t39A8Y3dnHzPDctir0evFLLcO381Rh ub4VVzU/7l9uxcO0c0Y1Ko9Jeqqa9fyd/20D0oB7ARY4sSO0ctnFyBuRuDTLMjmhmMf7 YbArUKlF6G3KoWHFALvesUbdjVIZC7+lOI2vQKO4hUhg9ZSVgMXOBIqn/sPTUVud58gY 8NRmgObPQ9cue8YnyE4L47Ja9CuqxX1+gCOfYWdMVF1HHi7K3heqnLhIpWGKF/+odQmB JvOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=Z6aWSipK+kRaeidN2tlNYW3+JjT4kZLJVZtiBhH1mwo=; b=E73MJNY6U8LwSUn8z+ivIYoujzQlW26sH3OgK0c7MfvKm+40vlo/tijPp/dcIRhoLP y8FYrFf62KJVZlvNpWVQYnRU3W6iyhyWRvrsHTD0s2H7x1yNrJ4trF8bXK26fGdwGMAW fwV9F9PYyi5fL8ugpYP3Qmzcov1uliOlbW3SzZDAMAe6ksPcWrv7OE9jacYwm1E7V/xe SckgiSj4L0xQ6AXDUDiBOIsxjAp9sGCHmN4qmgixslwOSZ/JquxXy+z/zckf+Vo5aIN0 alwqRgZMCl4Uv6lemioHYlmawNskvGecD2auU1/PHK1bG3zeSrnj/gBDY93M0HC/ObD4 T5ug== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id f142si671002wmf.1.2017.08.22.11.55.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 11:55:44 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id v7MItiUU025088 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Aug 2017 20:55:44 +0200 Received: from md1em3qc ([139.25.68.40]) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id v7MItiOW009551; Tue, 22 Aug 2017 20:55:44 +0200 Date: Tue, 22 Aug 2017 20:55:54 +0200 From: Henning Schild To: Baurzhan Ismagulov Cc: Subject: Re: [PATCH 0-10 of 16 v2 4/8] meta: conf: use bitbake.conf from bitbake and apply local changes Message-ID: <20170822205554.690876ef@md1em3qc> In-Reply-To: <20170822153102.GG4244@yssyq.radix50.net> References: <20170821132539.GD8387@yssyq.radix50.net> <20170821202940.2f4b43c6@md1em3qc> <20170822113129.GF4244@yssyq.radix50.net> <20170822144528.37e1cf5e@md1em3qc> <20170822153102.GG4244@yssyq.radix50.net> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: mYdqeIyQwQvx Am Tue, 22 Aug 2017 17:31:02 +0200 schrieb Baurzhan Ismagulov : > 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. >