[DISCUSSION] Issues, ToDo and Roadmap

[DISCUSSION] Issues, ToDo and Roadmap

[Claudius Heine]

Hi,

I would like to open a discussion about how we could improve the 
organization of Isar in regards to the projects short, mid and long term 
goals e.g. annoyances to be fixed, features to be implemented and bigger 
designs to work towards.

We currently only have two public ways of communication, one of which is 
not maintained. Those are the mailing list and the github issue tracker.

Mailing lists are great for open discussions and patches, but is a 
pretty fast moving medium and old discussions are no longer looked at 
and even get forgotten at some point so it might be sensible to put the 
results of discussions somewhere more persistent, search and with state 
tracking. Like a ticket system, issue tracker or wiki...

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?

Maybe have employ some bots to improve the short comings of the issue 
trackern and integrate the ML with it better?

What do you think?

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

Re: [DISCUSSION] Issues, ToDo and Roadmap

[Jan Kiszka]

On 11.02.19 11:19, [ext] Claudius Heine wrote:
> Hi,
> 
> I would like to open a discussion about how we could improve the organization of 
> Isar in regards to the projects short, mid and long term goals e.g. annoyances 
> to be fixed, features to be implemented and bigger designs to work towards.
> 
> We currently only have two public ways of communication, one of which is not 
> maintained. Those are the mailing list and the github issue tracker.
> 
> Mailing lists are great for open discussions and patches, but is a pretty fast 
> moving medium and old discussions are no longer looked at and even get forgotten 
> at some point so it might be sensible to put the results of discussions 
> somewhere more persistent, search and with state tracking. Like a ticket system, 
> issue tracker or wiki...
> 
> 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?
> 
> Maybe have employ some bots to improve the short comings of the issue trackern 
> and integrate the ML with it better?
> 
> What do you think?

I would start with something simple: If we think the issue tracker is an 
appropriate way to handle to-dos, let's clean it up first and use it. Then, if 
we do not run into the same state as today after a while again, we can think 
about improving its integration (if there is something that can be enabled with 
reasonable effort).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [DISCUSSION] Issues, ToDo and Roadmap

[Maxim Yu. Osipov]

Hi Claudius,

On 2/11/19 11:19 AM, Claudius Heine wrote:
> Hi,
> 
> I would like to open a discussion about how we could improve the 
> organization of Isar in regards to the projects short, mid and long term 
> goals e.g. annoyances to be fixed, features to be implemented and bigger 
> designs to work towards.
> 
> We currently only have two public ways of communication, one of which is 
> not maintained. Those are the mailing list and the github issue tracker.
> 
> Mailing lists are great for open discussions and patches, but is a 
> pretty fast moving medium and old discussions are no longer looked at 
> and even get forgotten at some point so it might be sensible to put the 
> results of discussions somewhere more persistent, search and with state 
> tracking. Like a ticket system, issue tracker or wiki...
> 
> 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?

Totally agree.
Let's use issue tracker - it's very helpful.

I encourage everybody to comment/revise the current issues (like Henning 
did for https://github.com/ilbers/isar/issues/8).

Thanks,
Maxim.

> Maybe have employ some bots to improve the short comings of the issue 
> trackern and integrate the ML with it better?
> 
> What do you think?
> 
> regards,
> Claudius
> 


-- 
Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mosipov@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov

Re: [DISCUSSION] Issues, ToDo and Roadmap

[Claudius Heine]

Hi Maxim,

On 11/02/2019 16.21, Maxim Yu. Osipov wrote:
> Hi Claudius,
> 
> On 2/11/19 11:19 AM, Claudius Heine wrote:
>> Hi,
>>
>> I would like to open a discussion about how we could improve the 
>> organization of Isar in regards to the projects short, mid and long 
>> term goals e.g. annoyances to be fixed, features to be implemented and 
>> bigger designs to work towards.
>>
>> We currently only have two public ways of communication, one of which 
>> is not maintained. Those are the mailing list and the github issue 
>> tracker.
>>
>> Mailing lists are great for open discussions and patches, but is a 
>> pretty fast moving medium and old discussions are no longer looked at 
>> and even get forgotten at some point so it might be sensible to put 
>> the results of discussions somewhere more persistent, search and with 
>> state tracking. Like a ticket system, issue tracker or wiki...
>>
>> 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?
> 
> Totally agree.
> Let's use issue tracker - it's very helpful.

I would be, if it was maintained. Which is currently not the case.

> 
> I encourage everybody to comment/revise the current issues (like Henning 
> did for https://github.com/ilbers/isar/issues/8).

Well that issue is one of those that should be closed as WONTFIX or 
similar just as Henning commented half a year ago.

I also don't really see myself a someone that should maintain those 
issues, since I don't even have permissions to close them. That is also 
IMO the maintainers or reporters job, since they should have the big 
picture or their specific issues in mind.

But with just a quick look at some of them (skipping already discussed 
#8), many can be closed IMO. Or course that is just my perspective. I 
have no idea if it is solved to the reporters or maintainers 
satisfaction, but if it isn't they should at least comment on why it 
isn't. Closing those issues might trigger them to comment if the close 
was premature.

Close #10 Allow cross-build for selected packages
Close #11 Enable non-root building (WONTFIX, I don't see that happening 
anytime soon)
Close #12 qemu: init 0 doesn't exit with qemuarm-jessie (WONTFIX, not 
sure why that is a isar issue)
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)
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)
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 #18 IMAGE_TYPE = "wic" (FIXED, as commented by Henning half a year 
ago)
Close or Update #19 Consider testing with http_proxy
Close #20 Override DISTRO_APT_SOURCE in local.conf? (no longer 
applicable AFAIK we now have DISTRO_APT_PREMIRRORS)
Close #21 Add support for package version pinning (fixed AFAIK, 
DISTRO_APT_PREFERENCES)
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)

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

Re: [DISCUSSION] Issues, ToDo and Roadmap

[Baurzhan Ismagulov]

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.


> 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.


> 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?


> 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.


> 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.


> 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?


> 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?


> Close or Update #19 Consider testing with http_proxy

Should be done in CI.


> 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


With kind regards,
Baurzhan.

Re: [DISCUSSION] Issues, ToDo and Roadmap

[Jan Kiszka]

On 12.02.19 12:17, Baurzhan Ismagulov wrote:
>> 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

Yocto is not comparable to normal distro installation, that's why Debian folks 
were skeptical as well - "maintainability" is the key.

> 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?
> 

The POC should ideally be linked in the issue. At least a status update would be 
good. I'm also missing links to follow-up discussion we had, e.g. around binfmt. 
Not sure anymore, though, if they were on the public list.

Jan

Re: [DISCUSSION] Issues, ToDo and Roadmap

[Claudius Heine]

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

Re: [DISCUSSION] Issues, ToDo and Roadmap

[Henning Schild]

Am Tue, 12 Feb 2019 12:17:11 +0100
schrieb Baurzhan Ismagulov <ibr@radix50.net>:

> 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.
> 
> 
> > 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.
> 
> 
> > 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?
> 
> 
> > 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.
> 
> 
> > 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.
> 
> 
> > 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?
> 
> 
> > 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?

Can be closed.

Henning

> 
> > Close or Update #19 Consider testing with http_proxy  
> 
> Should be done in CI.
> 
> 
> > 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
> 
> 
> With kind regards,
> Baurzhan.
> 

Re: [DISCUSSION] Issues, ToDo and Roadmap

[Baurzhan Ismagulov]

On Tue, Feb 12, 2019 at 01:40:02PM +0100, Henning Schild wrote:
> > > Close #12 qemu: init 0 doesn't exit with qemuarm-jessie (WONTFIX,
> > > not sure why that is a isar issue)  
...
> > In this particular case, I doubt this is going to be fixed in jessie,
> > so if that works with stretch, we could close that.

It does, closed.


> > > Close #18 IMAGE_TYPE = "wic" (FIXED, as commented by Henning half a
> > > year ago)  
> > 
> > Stated with a question mark -- could anyone verify?
> 
> Can be closed.

Thanks, closed.


With kind regards,
Baurzhan.