Re: [DISCUSSION] Issues, ToDo and Roadmap

[Claudius Heine <claudius.heine.ext@siemens.com>]

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