From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6514517411576676352 X-Received: by 10.223.160.4 with SMTP id k4mr823866wrk.14.1516802944139; Wed, 24 Jan 2018 06:09:04 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.214.21 with SMTP id n21ls2774566wmg.0.canary-gmail; Wed, 24 Jan 2018 06:09:03 -0800 (PST) X-Google-Smtp-Source: AH8x225qxXdoVg5RmMfx2BOhU9RB9iUDc2KK2rndRnL1r3dRkVe3mPzB/L/y3mhXq7jqIiG2rrEH X-Received: by 10.223.161.208 with SMTP id v16mr822877wrv.21.1516802943558; Wed, 24 Jan 2018 06:09:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516802943; cv=none; d=google.com; s=arc-20160816; b=CJ6KyOD7MnVXlPYtXfBf6rguw9WTbqPo/YK1Aq5Mx8/stuKzTXQEWm00xTWY4xcoj4 viN5bc03m8LAFmd9S+EeljSlMH/d/0OnrJAs4Hq84RGyGW+KKfnKoPokkXqtjKpxUzXN FHg5cVHHUupjIj5JBr34A9yutNOA0m57sfx12JaYy97aHwvIcEgvA+tmR8wbzozZtfOf PwpAKC3Nnje6PmpcZ0Ji08To3swjRdiGIcKWrh+Up59J8ZW13m+57yHATO3J2pfxioyf JLSvij4BeZBrtyv5IJxgGX72WUZ5Fw51opdmsd//oQq+KI7bharAC9cN1zZsjiLOR3L4 1rOQ== 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=IIRuobou9NwOwZ3bljuRrR5z37bx5P1lrGR/QpcJ2us=; b=P/xoq4mf7ZPNfBpIq1U9LHDkaerufHLrU8OkY8W7jty3GkDGG+nX/V+znSaeJCMUuk R4X5nl5K1p+oOeCYqCAEqEPz20tx+2HL0TJerRlHZ6qn8FuxGERGtD1+0OpBqg1ZLOU/ XK1PKIF8tzF3y2fHR1qG5NjMUL3gyjsI2rT7NRTHKEGOFlHit8nLD8xiinNRIbREYhJ7 W/47B43so2wV3iUS+ypr+NGQaIOEynH0FVYohL+5qgyMijYQJeyAFek8ocrwmsb6slHU TBb4VADB4o9gxvHvAmAe3DpDzZpwXbz3UWCs3xQnW8U19DdbVpdnDeSmtgHpY8pz8emC aYrw== 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 b10si32335wmc.0.2018.01.24.06.09.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 06:09:03 -0800 (PST) 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 (p2E51B0DF.dip0.t-ipconnect.de [46.81.176.223]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w0OE91NP017307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 24 Jan 2018 15:09:02 +0100 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 w0OE91No008843 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 24 Jan 2018 15:09:01 +0100 Received: (from ibr@localhost) by yssyq.radix50.net (8.14.4/8.14.4/Submit) id w0OE91HY008842 for isar-users@googlegroups.com; Wed, 24 Jan 2018 15:09:01 +0100 Date: Wed, 24 Jan 2018 15:09:01 +0100 From: Baurzhan Ismagulov To: isar-users Subject: Re: [PATCH] Factor out meta-examples Message-ID: <20180124140900.GD6434@yssyq.radix50.net> Mail-Followup-To: isar-users References: <23ca38c7-3718-f70f-532f-697b7023d69c@siemens.com> <6780b230-1481-8767-89a4-129be64d4319@siemens.com> <9fa572d2-8a59-b3b3-ab96-451975c72235@ilbers.de> <3e2ad3a4-9631-80bd-7c75-315d628b8d5c@siemens.com> <20180124130836.GA6434@yssyq.radix50.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-TUID: LXTrdfwQzE54 On Wed, Jan 24, 2018 at 02:39:13PM +0100, Jan Kiszka wrote: > > I've heard about this only offline. I support the idea of not having to delete > > Surely not. First, it's what I was proposing (and patching towards) for > ELC-NA 17. After that, all Siemens' major patches go in this direction, > all our products are built this way. No one should be surprised by now. It wasn't to say anyone was surprised. Alex's wish is to see the design principles we elaborate below (what goes where) formulated on this list. > > The same for machines. Could we define anything more specific than "arbitrary, > > reasonable minimum"? > > Only if we also test that. QEMU machines are both good test candidates > and good examples. I think they could stay with the core for the sake of > testability. Ok, so for now, it's still "arbitrary, reasonable minimum". > But we may also extract their architectural bits so that > you could reuse that definitions for own machines and have QEMU > instances in the example/testing layer. Hmm, in that case, wouldn't it be a pure rename action? meta -> meta-isar, meta-isar -> meta-example? Or do you suggest to move Debian configs to meta? > > This is simple, stupid. Even if there are use cases for meta alone: If we > > declare machines and Debian suite configs as the core, is there value in > > maintaining the separation of meta and meta-isar? > > Exactly. I can rework my patch in this direction, split it up, whatever. > > Besides that this general question of meta vs. metat-isar was nagging me > for a while, the current motivation to do something is to have the > reusable custom kernel recipes and an exemplary recipe that use them in > separate layers. My suggestion would be still "small steps": Review and merge reusable custom kernel in meta-isar, then reach the consensus on what goes where and do the complete move in a separate series. With kind regards, Baurzhan.