Re: [PATCH 0/4 v5] Isar apt deployment

[Henning Schild <henning.schild@siemens.com>]

On Thu, 19 Oct 2017 11:54:25 +0200
Baurzhan Ismagulov <ibr@radix50.net> wrote:

> On Thu, Oct 19, 2017 at 10:41:45AM +0200, Henning Schild wrote:
> > I will try to provide you with a way to reproduce the issue and will
> > look at the patch you attached.  
> 
> That would be great. You don't even need to spend time providing a
> minimal use case; I suggest that you provide your tree(s) as is
> off-list and we look at that with high priority.

I will have to look into that, one way or another i can not just give
you what i have.

> > Still the whole series went into next while it was still under
> > review and still had open points.  
> 
> The feature was in discussion since 2017-08-27. The last open points
> -- EEXIST and meta-isar-bin -- were addressed in v5. After no
> comments followed, the series was merged. It's after that that you
> report a build problem with an unpublished layer and suggest a
> completely new architecture.

The series was merged 3h after it was presented for review, my bad for
being so slow.
Issues not found in earlier rounds of reviews are still issues. And i
have heard many comments about that weird retry-loop, unfortunately not
everyone is active on the list.

> Under these circumstances, my suggestion is to make use of the
> existing feature v1 -- CIP and other people need that -- and
> implement the new architecture in v2.

It is not merged yet, it is just in a rebasing branch where you can
just drop it! But if you want to keep a known to be broken v1 go ahead.

> > That said i do not understand why you refuse to take it back out, i
> > can not work on next since these patches are in and i can not even
> > test the new stuff that was merged on top, same might be true for
> > other developers.  
> 
> Because the series works for all use cases known to us.

I would like to understand how the code expresses that do_cache_config
has to happen before the first do_populate.
As far as i can see it does not do that, so the race is obvious, but
might be hard to reproduce. My first guess is that BB_NUMBER_THREADS=1
might help get you there as well.
However if it is expressed, i will do my homework and find why that
expression does not work in my case.
 
> You are demanding to block the feature till you resolve the problem.
> But the win-win solution is to solve your problem. This is what we
> should aim at. We get mails from you since ten days, but what we
> would like to have is 1. your tree, as is, and 2. feedback to Alex's
> patch -- I see that as a homework before demanding the same for the
> third time.

1. only works in our intranet, sorry
2. i have provided that feedback several times and suggested
[lockfiles] and [depends] as means to deal with races and express deps

Henning

> 
> > Also the next q is getting pretty long  
> 
> We had intended to do a merge to master in Sep, but failed to do so.
> Merging the queues while short is exactly what we are trying to
> achieve right now.
> 
> 
> With kind regards,
> Baurzhan.
>