From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6656685609396994048 X-Received: by 2002:a2e:98cd:: with SMTP id s13-v6mr227272ljj.30.1549973886352; Tue, 12 Feb 2019 04:18:06 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:90ce:: with SMTP id o14-v6ls1951654ljg.11.gmail; Tue, 12 Feb 2019 04:18:05 -0800 (PST) X-Google-Smtp-Source: AHgI3IbtD4nlyh9ie9cOwaHUoJcXfm6AxZu6pjBT0HV0Jg+RHAQSO/LRj6zAqgMAwf/98TzcIZw4 X-Received: by 2002:a2e:505a:: with SMTP id v26-v6mr223450ljd.5.1549973885796; Tue, 12 Feb 2019 04:18:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549973885; cv=none; d=google.com; s=arc-20160816; b=0FTxfTGKOrK4mVfvtsTQJxe1T19oCm/SR9ZNs3rIO8P2mnKTh76GLykATTnRjBQZt7 gS3sf89qGNFcc1ZtY3RftsZjo2zYXR7FseOJFwHqMx5ugUZLUlnVmRkA65Pnu19xZw+n MMWfcxN9s/qlQySN/RuFomCyOc0YeL1xKR1gZw4WaRntJ8s2vo3QtPj3WFMJRAL/T22Y 44zIInPUmyIe3/JJg45J4dSvpPohJtgBIri24TdTL+Q7yG0Tqv0NCkJwTr8mDl/zjnTc L05M6S69WV4AkPNZ+3z7iym72Y3HIXd8oSu5a+mQPD0xQKcZtTKY/VJWbVLhcufO8Jl1 Le5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=8FHJd6+ecTWuID5VkYXm6Le3AG1oDuKepm5fZdnvGAI=; b=ovzfOPxwUkb1xKEMssgLQKMMCMUr8XShWld9CmAXNSLIHC28osIalN7QCbIYsR9xIA 8crD/zZLGBl5e3Taay/OXWKtRUKXzDE7Fy+eHKPv2/hYrEUcZRGpHuh5Zcd0DD7KYiMS K8UOxJd+ARLJRxO3bcF1gzCd2XUk0E67841SA8wfx5P6OGI47TMdDlj2bVLhazo81HIn 4Sz3EelWJ1AcG7WIp3+6lKIMeOit0q8B03w8snWvdXnPPcRslOyPgzSkoZ5bfMX+d2rr R1e8+Eg1/3fBv1imTwxdgTB3/oDtG823sZFDfIW/VHQQphBZlQDvIsaXJIICPzs68p+B n2Bw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id q10-v6si862943lji.4.2019.02.12.04.18.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 04:18:05 -0800 (PST) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id x1CCI5kM026059 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 12 Feb 2019 13:18:05 +0100 Received: from [139.25.69.181] (linux-ses-ext02.ppmd.siemens.net [139.25.69.181]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x1CCI4ls013952 for ; Tue, 12 Feb 2019 13:18:04 +0100 Subject: Re: [DISCUSSION] Issues, ToDo and Roadmap To: isar-users References: <71b39226-c243-2fb9-5988-cbf081c7d486@ilbers.de> <00a53485-81f3-1ac8-9649-00f04536f91a@siemens.com> <20190212111711.GH805@yssyq.m.ilbers.de> From: Claudius Heine Message-ID: Date: Tue, 12 Feb 2019 13:18:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190212111711.GH805@yssyq.m.ilbers.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: 7tIprf3+NN7i Hi Baurzhan, On 12/02/2019 12.17, Baurzhan Ismagulov wrote: > On Tue, Feb 12, 2019 at 10:12:09AM +0100, Claudius Heine wrote: >>>> The github issue tracker of Isar is in a very sorry state. Some of >>>> those open issues are no longer applicable or already fixed. Maybe >>>> we could reactivate that and have some more moderators to keep that >>>> up to date? > > FWIW, the issue tracker is good as a TODO list. The ML is good for discussions. > I'd like to keep both. > > I agree that the tracker needs more attention. Maxim will look at that. > > OTOH, maintaining != closing ASAP. The OP should get a response, but I don't > see a problem in having an issue for a long time if we want to have in Isar. Well people that open feature issues and the overall maintainer of that part should be responsible for maintaining that. Isar is currently a code driven project, so if someone opens a feature request that might just be 'nice to have', but nobody cares about implementing that, should that stay open indefinitely? In my opinion no. It should be closed after a reasonable period of no update with a label or comment saying that there is currently not enough interest to actually implement it. If someone later comes along and implement is, than it can be reclassified as resolved. But letting them stay open for a long time just produces noise. Maybe as a compromise leave it open but label it as feature-request so it can be hidden until all bugs are resolved. >> Close #10 Allow cross-build for selected packages >> Close #21 Add support for package version pinning (fixed AFAIK, >> DISTRO_APT_PREFERENCES) > > If that works and is documented. If it doesn't then open an issue about that. Otherwise this is a feature request issue and that feature should be implemented. > > >> Close #11 Enable non-root building (WONTFIX, I don't see that happening >> anytime soon) > > We have a stale PoC implementation. If Yocto does it, it should be possible. It > might not be the highest priority ATM, but it would be nice to have. Maybe > someone seeing it would have enough itch do do that. Otherwise, how do you > suggest to communicate the roadmap you are talking about? IDK, but I guess we can try to look into how other projects on github handle that. Putting labels to signify bug/feature/design/wish, expected difficulty, priority, ... whatever and putting milestones on issues to signify the roadmap etc. >> Close #12 qemu: init 0 doesn't exit with qemuarm-jessie (WONTFIX, not sure >> why that is a isar issue) > > That is an interesting perspective, thanks. Formulated in this way, I have to > agree :) . I've seen that in a way that Isar provides stuff that works and > tracks upstream issues just like Debian. So, in general, my approach would be > at least to report that upstream before closing here. > > In this particular case, I doubt this is going to be fixed in jessie, so if > that works with stretch, we could close that. IMO it doesn't make sense to report non-isar issues to a isar bug tracker. So I would close is immediately with a link to the debian bug tracker. Isar needs to put down its exact scope, because it does not have the manpower to resolve every single issue in a Debian image it produces. If the same bug occurs upstream, then that is 'not a bug' from isar perspective. > > >> Close #14 bitbake: Multiconfig builds seem to be serialized (if that is >> still true, then that is a bitbake issue and needs to be fixed there not in >> isar) > > Yes, fix in bitbake. Affects Isar -- TODO here. Again, we don't have the manpower to fix bugs in other projects, if the bug is not in scope of isars code base, then its 'not a bug' in isar and should be removed from the tracker with a link to the bitbake ML. Using the isar bug tracker to track personal todo lists for projects that are not isar does not make sense to me. If bitbake has concurrent build of multiconfigs and isar does not uses it correctly, then that is a reason to have such an issue. > > >> Close #15 Support AUTOREV in SRCREV (WONTFIX, that is a feature issue that >> is open for 1.5 years with no update, there seem to be no interest for this) > > But would it be useful if it existed? My answer is yes. So what is the problem > with having a wishlist? Wish lists are fine if those wishes are reasonable, have some motivations and use scenario description. But at some point there needs to be a action to implement or work towards it. If the action is missing, then this is just noise on the issue tracker. See my comment above. >> Close #16 Jessie: Host configuration leakage around apt-get (WONTFIX, we >> don't use multistrap anymore) >> Close #17 wic does not find mkdosfs (FIXED, as commented by Henning half a >> year ago) >> Close #20 Override DISTRO_APT_SOURCE in local.conf? (no longer applicable >> AFAIK we now have DISTRO_APT_PREMIRRORS) > > Thanks, closed. > > >> Close #18 IMAGE_TYPE = "wic" (FIXED, as commented by Henning half a year >> ago) > > Stated with a question mark -- could anyone verify? IMO that issue is resolved! There is a 'wic-img' image type and the current ci build uses wic to produces images. Henning was not the person reporting that bug or the maintainer, so only them can verify that this issue is resolved and close it. If they aren't happy with how that issue was resolved they should comment and clarify what they expected from it. As I already said: Nobody else than the reporter or maintainer can verify if the issue is solved to satisfaction or not, because they are the only ones that can either check if their problems does not occur any longer (reporter) or if they think that this issue is correctly solved in scope of this project (maintainer). Of course in some cases the developer can also solve their understanding of the issue, but often they work independently from the issue tracker and just by chance fix issues there. Reporter and Maintainer should then sync that. > > >> Close or Update #19 Consider testing with http_proxy > > Should be done in CI. Andi submitted some patch. No comment further about if that patch is merged or if that resolved that issue or if there were some problems with it that needs further revisions for over a year. We have to look at ML archives now to figure out what happened here. Because there is no information about how the patch was received here the state of that issue is unknown for a long time now, so closing it makes sense to me. But it would be best if the reporter or maintainer check first if that is fixed to satisfaction or not and comment on it if that is still an issue so it can be worked on. >> Close #27 bitbake: Consider reading bitbake's and project's config (fixed >> AFAIK, we don't use the bitbake.conf from bitbake but have our own) >> Close #28 Document bitbake.conf concatenation (fixed AFAIK, since we don't >> concatenate anymore) > > Project-specific bitbake.conf from scratch is the way described in the bitbake > docs [1] and was implemented by Isar in the beginning. Inheritable bitbake.conf > was suggested later; I am personally not sure what the value is. I've closed > that > > References > > 1. https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#the-hello-world-example That is a really old bitbake version. Things have changed. regards, Claudius -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de