Re: [PATCH v2 00/16] wic integration

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

Am Fri, 4 May 2018 11:32:20 +0300
schrieb Alexander Smirnov <asmirnov@ilbers.de>:

> Hi,
> 
> On 05/04/2018 11:16 AM, Henning Schild wrote:
> > Am Thu, 3 May 2018 19:39:39 +0300
> > schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >   
> >> On 05/03/2018 07:32 PM, Henning Schild wrote:  
> >>> Am Tue, 1 May 2018 22:23:01 +0300
> >>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >>>      
> >>>> On 04/13/2018 05:18 PM, Henning Schild wrote:  
> >>>>> This series does the follow things:
> >>>>>
> >>>>> 1. revert all changes that where made to wic so Isar uses an
> >>>>> unmodified version of it
> >>>>> 2. Introdcue an image-class that will create wic images
> >>>>> automatically 3. enable testing that in CI
> >>>>> 4. update docs
> >>>>>
> >>>>> Patches 1 to 7 just deal with getting back to an unmodified
> >>>>> version of wic.
> >>>>> Patch 11 - the big one - provides the real functionality.
> >>>>>
> >>>>> I will provide some more information on what is going on here by
> >>>>> replying to p11.
> >>>>>
> >>>>> Major changes to the first series:
> >>>>>     - rebase on recent Isar
> >>>>>     - wic is now running in buildchroot, as root
> >>>>>     - calling wic manually not supported any longer
> >>>>>     - distros before stretch are not supported either (see p11
> >>>>> discussion for why)
> >>>>>     - CI can now test wic for the first time  
> >>>>
> >>>> Applied to next, thanks!  
> >>>
> >>> Thank you. I have one outstanding change i wanted to squash with
> >>> p11, originated from a review from Claudius. Should that get
> >>> squashed or go on top?
> >>> https://github.com/henning-schild-work/isar/commit/75bbea59fe2e4174f4eaf0f782792d208672fad6
> >>>      
> >>
> >> I'd prefer on top, could you please send this patch on the list?  
> > 
> > And now i remember another "open" point. Claudius suggested to split
> > the forking of the plugins into two steps. One that just copies
> > them, and a second to apply the Isar-specific changes.
> > That would make it easier to see what needed to change to make them
> > work under Isar, which could become increasingly interesting when we
> > version-bump our wic some day.
> > 
> > I could do that on top as well, sort of two no-op patches. But in
> > this case a rebase would probably be the better option. Or we do
> > not do that at all. How would you like to proceed?
> >   
> 
> If you specify the commit to drop and provide two patches, I could
> force the history.
> 
> But in general I'd prefer updates-on-top, because this way has lower 
> probability of mistake. I know that current head is fully functional
> and incrementally tested. If something is updated in the middle of
> history - I have to check that this doesn't corrupt patches above.

I just sent two patches on top. Applying both is a no-op and they might
help understand what is Isar-specific in the forked files.

Henning

> Alex