Number and codenames for GDP next.

Andersson, Gunnar gunnar.x.andersson at volvocars.com
Fri May 20 07:15:56 EDT 2016


Hello all

I have been staying out of this discussion to understand what exactly the problem is, and many good emails have been exchanged already.

But I hope by now some important points have come across.  

First that we *can* work on improvement also in meta-ivi, but I suggest in an incremental fashion as opposed to big bang.  More about this later but I would recommend to move such proposals out into separate discussions.  This thread is simply trying to do to much at the same time. 

But please relax a bit first.  We can in fact live with the current situation and do a lot more important improvements in GDP instead, to be honest.  (That a particular git repository has the same name as the name of a directory within it is not the end of the world, seriously).

Also I think it's clear that some more extreme proposals in this thread have been made without a proper understanding of both the historical and the current purpose of meta-ivi and baseline delivery.  Thanks to Pavel for jumping in and correcting those things while I did not have time.  In the last email he also describes it very well.  But I imagine we might need to go through some of these things again and ensure they are understood.  Because even after Pavel explained earlier what meta ivi and baseline was, the idea that GDP shall take the place of the baseline was repeated.  Let me make clear that this is *not* in the near plans right now.  

Very briefly repeating from Pavel:  GDP is not a minimal set of compliant components but the baseline is, and that's a useful thing for adopters of GENIVI, for those systems that are not GDP.  I hope we all realize also that a baseline is also not the same as a list of "GENIVI components" if by GENIVI components is meant that which is on git.projects.genivi.org and github.com/GENIVI.  There are many adopted components with special requirements - some with patches that need to be applied (we try to minimize that of course), others with particular version requirements, and so on.  Whether the so-called GENIVI components should be in a separate layer without any adopted components recipes can also be discussed in isolation (I would then refer to all the layer strategy input I've given before which may include AGL reuse...)

Another reason is that GDP might also potentially be non-compliant for brief periods of time and having that possibility is a good thing.  The reason is that we may want to show some software that is covered by GENIVI specifications but not included in the Baseline.  A system tailored to development support might include software that supports some aspect of development but is not appropriate for production use, and therefore not a candidate for compliance spec or baseline.   We need a place where we can be flexible with trying out software in proof-of-concept stage when that makes sense.  PoCs may lack or incorrectly implement some partial function that the specification includes.   

If any reader was surprised by that there can be components in GENIVI compliance spec that are not in the baseline then I have to refer you to some very basic things in the platform compliance program, namely that we have Placeholder, Abstract and Specific components, i.e. different ways to specify requirements.  That's as far as I intend to discuss the compliance spec on this mailing list because it is one of few things that are not a public artifact from GENIVI.  I'm happy to discuss it a conference call if you wish, or you can do the required reading in the GENIVI Wiki.

On the same note, someone else indicated that basing GDP on the baseline would make GDP compliant.  Not strictly true.  Simply using the baseline is not a _sufficient_ condition for a system to be compliant, because the specification is more than the subset of software the baseline can provide.  Confusing?  Think of it this way - the baseline itself is compliant but any software you then add has a possible chance of conflicting with the specification.

That said I do support all efforts to make GDP as compliant as can be!  If you reach 100% compliance, feel free to prove me wrong and you may ask again if it can replace the baseline, but not before that please.  Such a system would still not fulfil the "minimal set of components" and other goals of the baseline, but we could repeat the discussion then.   
;-)  

So let's now go ahead and improve GDP and continue to base it on the baseline as a good first step.  It's much better use of our time.  Understand that GDP will not replace the baseline in the very near term at least.

Let's also go ahead to step by step improve the structure of meta-ivi and discuss those change proposals that still ensure that it acts as a baseline.  You can even suggest a rename, but one thing at a time.  I am sorry but some of the issues brought up are not urgent changes so I recommend again that we calm down and work incrementally, just like we propose patches to any software.  For example, maybe the BSP can/should be moved somewhere else.  Maybe we can avoid the custom distro and just reuse another distro (from yocto/poky?), but please then do that analysis first and describe the consequences.   Maybe we can put some recipes in one layer and image or distro definitions in another and create a combined baseline out of that (Rudi's final proposal got closer to something actually workable but I don't prefer a big bang as I said).   Each of the points can be discussed by itself.  Rudi's  simple statement "this is a mess" I do not accept.  First because it is a misrepresentation of not very critical problems.  The repository is used successfully in both GDP and in Infotainment product development, even if the distro file that is there happens to be ignored.  So work towards cleanliness, sure, but in an orderly manner.  All baseline related discussions are BIT Team subjects, and if required we can adjust meeting times to participants when needed.

We are also currently in a very important discussion to redefine BIT charter and clarify the requirements on testing the baseline vs testing GDP.  Testing the baseline requires a testable image and it requires us to test specifically the set of components that the baseline provides.  This can currently be done with meta-ivi, and can of course in theory be done with a different layer structure also.   Again I would move this incremental improvement discussion to a BIT forum.

Thanks for understanding and Best Regards

- Gunnar


-- 
Gunnar Andersson
Lead Architect, GENIVI Alliance
Infotainment, Volvo Car Corporation

> On May 19, 2016, at 14:02, Konopelko, Pavel (P.) <pkonopel at visteon.com> wrote:
>
> Rudi,
>
> Streif, Rudolf wrote on 2016-05-18:
>> Thanks for the explanation.
>>
>>> In the early days of GENIVI, there was a compliance specification
>>> and baselines.  The compliance specification defined constraints on the
>>> compliant distro.  Each baseline provided a minimum functional (i.e.,
>>> boots in QEMU to console) distro within these constraints.  "Minimum"
>>> was a way to reduce the maintenance cost on the one hand, but also to
>>> make sure that the people adopting the baseline for their products will
>>> not be in the position of removing things they don't need (which is
>>> typically more difficult compared to adding things).
>>
>> Ok, that makes sense then.
>>
>>>> From my understanding, GDP and the Yocto GENIVI Baseline should
>>>> be the same thing.
>>
>>> Personally, I see no reason why Yocto GENIVI Baseline cannot be a
>>> part of GDP (i.e., a separate layer).  For me it is important to keep
>>> the baseline separate, though, since it would make it easier to
>>> [re-]use it for building products.
>>
>> The problem I have with this is that meta-ivi is not just a middleware
>> layer but it's a distribution layer. If I include meta-ivi with GDP or
>> any other distro I am building, I have a distro layer wrapped inside a
>> distro layer with a lot of stuff I don't need and want. I would want the
>> GENIVI components in a separate standalone layer (with standalone I mean
>> having its own git repo) so that I can include just that.
>
> meta-ivi used to be the only game in the town and therefore was self-contained.  Now that the scope of GENIVI development grew broader to include GDP it seems to be just about the time to refactor things.
>
>>>> If they are not, I probably need somebody to explain to me. Here
>> [1] it says: > > > > "The Yocto GENIVI Baseline is a Linux distribution
>> for a variety of > > embedded devices, based on meta-ivi > >
>> <http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi> . The project > >
>> aligns itself with The Yocto Project <https://www.yoctoproject.org/> ,
>>>> and the distribution is the result of making the Yocto Project
>> reference > > system Poky <https://www.yoctoproject.org/tools-
>> resources/projects/poky> > > aligned with the GENIVI Alliance compliance
>> specification." > > > > If I go to the download link [2] all I get is
>> links to the Yocto Project > > git repo location of meta-ivi. I don't
>> even understand what meta-ivi > > wants to be. > [...]
>>
>>> If you ask me, meta-ivi wants to be a distro that is GENIVI-
>>> compliant and boots to console in QEMU.
>>
>> That is fine and good. I just want to be able to reuse some of the parts
>> of meta-ivi without being burdened by the rest of it. In that sense, I
>> am proposing a standalone meta-genivi layer that gives me the GENIVI
>> components and just requires OE-Core and eventually other base layers
>> but does not have any machine or distro configuration associated with it.
>
> As already said, nothing about meta-ivi is cast in stone (as far as I am concerned at least).  Let's agree about what we are trying to achieve and then change things (hopefully for the better :-).
>
> From the GENIVI compliance point of view here are the requirements (that meta-ivi currently caters for):
>
> * There shall be an efficient way to validate whether the list of components in the GENIVI Software Platform (read compliance specification) can be distributed together given their version constraints.
> [Rationale: Any version conflicts are much easier to detect by trying to build a distro and do at least some smoke testing with the result.]
>
> * There shall be a way to obtain recipes for building the components in the GENIVI Software Platform such that the number of any other components (e.g., unnecessary dependencies or unrelated components) is minimized.
> [Rationale: When building a GENIVI compliant distro for a product it is easier to take a minimal, compliant core and then extend it as compared to tearing apart a web of interconnected components most of that are not needed.]
>
>
> Regards,
> --Pavel Konopelko
>
> _______________________________________________
> genivi-projects mailing list
> genivi-projects at lists.genivi.org
> https://lists.genivi.org/mailman/listinfo/genivi-projects



More information about the genivi-projects mailing list