From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6450015460633083904 X-Received: by 10.25.157.20 with SMTP id g20mr249806lfe.15.1503487906026; Wed, 23 Aug 2017 04:31:46 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.83.20 with SMTP id h20ls505382ljb.3.gmail; Wed, 23 Aug 2017 04:31:45 -0700 (PDT) X-Received: by 10.25.215.223 with SMTP id q92mr251487lfi.30.1503487905399; Wed, 23 Aug 2017 04:31:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1503487905; cv=none; d=google.com; s=arc-20160816; b=JqL50xGLRbi6YuNixL0kV+yPELtfKbXhFuOSh1+j833CQtp0NNbBN3jsV4xIPO7bgF On6UU0gk254+Nkr35UbO2r63Kf3eqKUwAj/lGDlOLY3iWLNX1pMmOzu7kxbehTei/yIN mFXQHOoBmNPiA3+eKQsKjS6Tw+UHPDiUSbcXj8q/MlXgMRan0PpHJZ+Npf4YCrqOymBX J3EQJREkqzmjc6980PJDrxNVRAayFScs9g4TwYr2TPqYNrWyXL70pItv1ApuxaA6Y26C PC0j665l8jPHiNN5CjZPzB0QpbMLWDsohNo4Qdic03zlncewZcIvbUNQyhnGl1oXggXg kN6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date :arc-authentication-results; bh=H1o4/3G5fL9r5JVKijk7rWHiz6gieerRKWemeBZcIgA=; b=TrevE09VimpVu36dzqnhm/03zsfkygp0qR0lKy+rAi3MNOS/2WbJ56a5v7Gf+BAZ/q aWSZ6YtuUkCHzEs3gyRhGkhPyHgfl9BOK+xTF+E9TglNg7faqz1qoW+Om2SYtYdvEUmG krHrFpuEXDkeFbjJ/Q8UqVE1VV29tu2oxgaLdd4juX1MdEEhk7S2NhVhnjEI5uaUMRRt K2fKUCbAVgD5Kn6woeCCvRORqanHtwuHjnPmNCKnUKDRAd2AxaO97fRE3oBZLmzT68kh MeAvHFD/9VnuR8/kq64dPJo9c817bmeppUtFdPFjt1KU+R0yP4X+jWdpBB0eZaPHIrN+ nrwA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id 72si242788wmo.9.2017.08.23.04.31.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 04:31:45 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.radix50.net (p5B2DC7BC.dip0.t-ipconnect.de [91.45.199.188]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v7NBVgLf018163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 23 Aug 2017 13:31:44 +0200 Received: from yssyq.radix50.net (localhost [127.0.0.1]) by yssyq.radix50.net (8.14.4/8.14.4/Debian-8) with ESMTP id v7NBVgeI011478 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 23 Aug 2017 13:31:42 +0200 Received: (from ibr@localhost) by yssyq.radix50.net (8.14.4/8.14.4/Submit) id v7NBVgXL011477 for isar-users@googlegroups.com; Wed, 23 Aug 2017 13:31:42 +0200 Date: Wed, 23 Aug 2017 13:31:42 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [PATCH 0-10 of 16 v2 4/8] meta: conf: use bitbake.conf from bitbake and apply local changes Message-ID: <20170823113142.GB5580@yssyq.radix50.net> Mail-Followup-To: isar-users@googlegroups.com References: <20170821132539.GD8387@yssyq.radix50.net> <20170821202940.2f4b43c6@md1em3qc> <20170822113129.GF4244@yssyq.radix50.net> <20170822144528.37e1cf5e@md1em3qc> <20170822153102.GG4244@yssyq.radix50.net> <20170822205554.690876ef@md1em3qc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170822205554.690876ef@md1em3qc> User-Agent: Mutt/1.5.23 (2014-03-12) X-TUID: bgfzZhis+gb6 On Tue, Aug 22, 2017 at 08:55:54PM +0200, Henning Schild wrote: > Ok, understood. I think using issues as reminder list might shine the > wrong light on the project, but that is a personal feeling. This is a good point. At least small stuff like two lines of docs would really be better to do immediately and not to postpone. Bigger stuff like upstream bitbake changes would still exist. One approach could be to distinguish between user bugs and project own TODOs (not offered by GitHub). We've discussed this with Alex; ATM, we'd prefer to stick to the existing infrastructure, at least till the development is streamlined. Internally, we have an even longer list of issues and plan to move them to GitHub for now as well. > 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. The original plan was supposed to be faster due to quick fixes without later review. Since we want a final review of changes, let's switch back to the classic process. > Or at least end up in "the official" next branch where it will > sit for a few days for everyone to look at. Ok, we've discussed this with Alex and would like to introduce next. Currently, we are checking whether we still need asmirnov/next, and what implications that would have on the maintainer process. We also have some wishes: * When submitting patches, considering the stuff from CONTRIBUTING would help us to review them, especially w.r.t. communicating the background / motivation / intention to work at something early in the process. * We'll comment on the desired formatting. CodingStyle is on my TODO. * If there is a problem, please articulate expectations; that would allow us to address them (unlike e.g. just a request to revert). * We've looked at the apt implementations and currently tend towards the existing one, as it supports binary package caching and is shared with the Deby project. Regarding reprepro, we'd like to keep it because dropping it would mean re-implementing that in Isar and keeping up with possible Debian archive structure changes in the future. With kind regards, Baurzhan.