From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6659262894210809856 X-Received: by 2002:a50:d4c4:: with SMTP id e4mr3001156edj.10.1550510199346; Mon, 18 Feb 2019 09:16:39 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:406:: with SMTP id d6ls2688317eja.7.gmail; Mon, 18 Feb 2019 09:16:38 -0800 (PST) X-Google-Smtp-Source: AHgI3IaS8y83XGT6cLI8JJSspKcMgm8lTGDql5QPEsVH0x8Lkby8FRHa5lchwZMqfKRbiqNwBD7e X-Received: by 2002:a17:906:8da:: with SMTP id o26mr154112eje.7.1550510198903; Mon, 18 Feb 2019 09:16:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550510198; cv=none; d=google.com; s=arc-20160816; b=JPQjjO7xwo/I1zZixZwKFI0HSh4Mczwn3oGNg9ios1XidcF6vF5QnfuoAhuNQuVXxM BlZ3gr10WBmThA0YWWAzPB1z1Fzf4F7ECg8WCMyr7h4aAANQAy4jGPR4RXFIcObXRjyg vXj2ThB4JOVc0exDv6C7umsRYt403/NMbFLJI2dwgG7dJqG+2saiA3cJ3MeCGE+ow6l6 AIWlw2zEmWAH5A8g6StqTtKnGiZN5c2QX88V482O0fztV5/ei58u3v5i6vYmF4WNcoX4 Nrkhp0XFC0EJ8wJh9t4oz1KXmlerfaE/FBA7tPYT9tdIKDWLSzeFEPrjJx0YiKZWXULa 9jPA== 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; bh=g35l1Z6WTEnFcKarlrswJQIn0x5pO04Cp8ZK/KaQ7wM=; b=y1lgMU+Axztl0Sz9IekVeGmcCWj8dZipZE0Vb8Kh5ZFwxCW6Kt5s6JIx2kh2zEn7Yj gWWJZQHol/0GnYlY5ZgUi9xtbxMcomVvOBY2EsrhNRnugIZpQhhjtsC6OuGanbEfiC+M tOlb2SxYtsr8IET6ZZA+rVlRflR7yS7wsfiCNSfm3e35gSuorQ9fFfkCRTsmNm9kOmX1 FbOaHdywJAgHmQflnan7QjkxBF1NXJZg9UCJXlbs07uoErsv4gc9Iyz0T/4+iX7ca+sW 6nVXiPXe2oCV1B6kYamyC8veZCJKt3/6nsX9mkEYDyP+aL9+jpUpa96Vwr74bKk+eYOy wfmg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id j6si631572edd.0.2019.02.18.09.16.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 09:16:38 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id x1IHGcDH008535 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 18 Feb 2019 18:16:38 +0100 Received: from md1za8fc.ad001.siemens.net ([139.25.0.6]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x1IHGcqg002583; Mon, 18 Feb 2019 18:16:38 +0100 Date: Mon, 18 Feb 2019 18:16:36 +0100 From: Henning Schild To: "[ext] Claudius Heine" Cc: "Maxim Yu. Osipov" , isar-users Subject: Re: [ANNOUNCE] Upcoming ISAR release Message-ID: <20190218181636.33357681@md1za8fc.ad001.siemens.net> In-Reply-To: <206fc335-0158-6288-a23a-e34852c12784@siemens.com> References: <96e3ec90-3a4d-dcb0-1645-725d5d7d7094@siemens.com> <55b9ae17-4e39-7f65-2a0e-29b8173c814e@ilbers.de> <206fc335-0158-6288-a23a-e34852c12784@siemens.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TUID: LZ01bm6u/M77 Am Mon, 18 Feb 2019 12:52:18 +0100 schrieb "[ext] Claudius Heine" : > Hi Maxim, >=20 > On 18/02/2019 11.29, Maxim Yu. Osipov wrote: > > Hi Claudius, > >=20 > > Thanks for the feedback. > >=20 > > OK, let's focus for v0.7 release for now. > >=20 > > On 2/18/19 10:58 AM, Claudius Heine wrote: =20 > >> Hi Maxim, > >> > >> On 18/02/2019 10.01, Maxim Yu. Osipov wrote: =20 > >>> Hello everybody, > >>> > >>> Last release (v0.6) was made on 1st of October 2018. > >>> > >>> We plan to release the next version of ISAR on 1st of March, 2019. > >>> > >>> BTW, what do you think about making a 1.0 release? =20 > >> > >> IMO we need a lot more cleanup stuff before we can do a solid 1.0=20 > >> release. > >> > >> We should make a list of issues that should be done before 1.0 > >> release. > >> > >> Here is a suggested checklist before 1.0: > >> > >> =C2=A0=C2=A0- Remove jessie support =20 > >=20 > > That's a point which I don't understand - yes, we don't support > > jessie as a host system, but why don't continue to support jessie > > based targets if this doesn't require big efforts? =20 >=20 > Well IMO it does require effort as shown with the unavailable `-d`=20 > parameter in mkfs.ext4. For image creation not the build machine > tools should be used but those of the host (or what you call target), > which should then be >=3Dstretch. The image creation tools might have > patches applied to them. >=20 > > Industrial programming is very=20 > > conservative in this point (that's why all these=20 > > https://www.cip-project.org/ serve for). =20 >=20 > That has nothing to do with this. linux-cip is a project to support=20 > kernel versions for ~25 years. AFAIK nobody does that for the > userspace. >=20 > > =20 > >> =C2=A0=C2=A0- Improve documentation > >> =C2=A0=C2=A0- Cleanup the user interface variables > >> =C2=A0=C2=A0=C2=A0 - Consistent variable nameing style =20 > >=20 > > naming ;) > > =20 > >> =C2=A0=C2=A0=C2=A0 - Use feature variables instead of many VAR=3D"1" o= nes. They can > >> be more easily bundled together in code and docs. =20 > >=20 > > I vaguely remember this discussion. > > Could you please provide arguments why we will benefit from that? =20 >=20 > - fewer variables to remember, which lead to > - easier to document > - better learning curve > - better UX > - Features are easier to work with, because > - single place in 'bitbake -e' where they are condensed > - easy to read names, because variable names need to have some=20 > additional 'namespace information' > - Similar to OE, which lead to > - easier switch for OE people to and from Isar > - easier to compare feature set of OE and Isar > ... >=20 >=20 > >> =C2=A0=C2=A0- Consistent and clear naming of things > >> =C2=A0=C2=A0=C2=A0 - Build, host, target in line with GCC and Debian d= efinition =20 > >=20 > > Could this renaming confuse current Isar users? =20 >=20 > This is much more confusing IMO: >=20 > meta/recipes-devtools/buildchroot/files/common.sh > 26: set_arch=3D"--host-arch $target_arch" I was about to cite exactly that statement ;). We either confuse a few people using cross on Isar, or everybody else. Debian did not invent the naming either but that seems a natural choice to align with. That is a TODO i never finished. It was never meant to be merged but to raise attention. https://groups.google.com/forum/#!topic/isar-users/QU10HPRVlFc Henning > Of course that will confuse current Isar users, but IMO current Isar=20 > users are used to be confused most of the time they work with Isar=20 > anyway ;) You have to take care not to confuse new users, since that > is the critical period where you really want to make it easy for them. >=20 > We will need to break this at some point, better do it before 1.0. >=20 > > =20 > >> =C2=A0=C2=A0=C2=A0 - meta, meta-isar -> either meta and meta-example o= r meta-isar > >> and meta-isar-example. Currently 'meta-isar' sounds like it is > >> required. > >> =C2=A0=C2=A0- Clearly defined task pipeline for all recipe types > >> =C2=A0=C2=A0=C2=A0 - no more do_build with stuff in it, that should be= treated a > >> the default target not some real one > >> =C2=A0=C2=A0=C2=A0 - dpkg_runbuild should be a task with postfunc and = prefunc=20 > >> attributes to wrap mounts around it > >> =C2=A0=C2=A0- Cleanup meta-isar layer to show best practices of using = isar > >> =C2=A0=C2=A0=C2=A0 - multiconfig should not contain other variables th= an DISTRO > >> and MACHINE =20 >=20 > Here some more: >=20 > - IMAGE_INSTALL should not add itself to DEPENDS, that breaks recipes=20 > that produce more than one Debian package > - support of IMAGE_TYPE with more than just one image type > (IMAGE_TYPES) >=20 > I still expect more of those... >=20 > >> > >> I am sure I will find a lot more of those if I think a bit harder=20 > >> about it. All of those issues makes adopting Isar for new, OE or=20 > >> Debian people alike very difficult. With the 1.0 we should try to=20 > >> bring Isar to a level were we don't expect many breaking changes > >> on the next 1.1 release. > >> =20 > >>> At the moment I'm busy with testing/applying pending patches, I > >>> plan to finish this activity in a couple of days and make a first > >>> release candidate and code freeze (only bug fixes will be applied > >>> in the 'next') after that. =20 > >> > >> Shouldn't we open a release staging branch for that, so that > >> feature submissions can continue to next? =20 > >=20 > > Does it makes sense for now with the release cycle taking one > > week? =20 >=20 > If you think that works, then ok. Personally I don't really care > about the releases <1.0 since they get old rather quickly, but I > don't want to stop the progress, since there is so much still to do > in Isar. >=20 > regards, > Claudius >=20