[Openembedded-architecture] Notes from the OEDAM "Naming Table"
Philip Balister
philip at balister.org
Fri Sep 9 12:24:01 UTC 2016
On 09/08/2016 04:14 PM, Trevor Woerner wrote:
> I hesitate to weigh in because this is a big issue that can only really be
> decided by the major players in this project, and I'm well aware of the fact
> that I'm not one of those people.
You are exactly the sort of person we need engaged in this sort of
discussion. We (the project) need to do a better job of listening to all
developers and users.
Philip
>
> But on the other hand, I don't want the silence to be interpreted as
> non-interest. So instead of pestering everyone with "me too" replies, I'll try
> to be succinct.
>
> On Sat 2016-09-03 @ 12:14:57 PM, Martin Jansa wrote:
>> 3) confusion between poky as a DISTRO or as a git repository,
>
> Ideally poky could be a DISTRO and nothing else and be named meta-poky and
> exist as its own, top-level layer. (or, if moving forward with the name "poky"
> is too confusing then pick something else and make that the de-facto Yocto
> reference distro).
>
> Imagine if every DISTRO maintained its own repository with a "meta"
> subdirectory that was simply a copy of OE's meta, and a "bitbake" subdirectory
> that was simply a copy of the bitbake project. It wouldn't take long before
> someone would come along and refactor everything. Of course, over time, all
> these "meta" and "bitbake" subdirectories would diverge and show various
> levels of maintenance and become a large headache for anyone actually trying
> to work on products!
>
> I guess poky, the repository, is useful because it allows the project to skirt
> the issue of whether to use git submodules, or repo, or whatever else? Are
> there other benefits? Hopefully at some point the duplication maintenance
> would outweigh this benefit?
>
> It seems disingenuous to be, on the one hand, teaching people that in order to
> produce an image for a device one needs to obtain the correct BSP layer,
> select a DISTRO layer, then combine that with the OE/meta boilerplate in order
> to build. Then, on the other hand, combining all the above into the poky
> repository to save everyone the effort. Of course, I know some of the people
> involved in this project and know that they are all very sincere people;
> therefore I know they're not intentionally trying to confuse people, but I
> could see how someone might wonder about this apparent bait-and-switch.
>
> The poky repository is vitally important because the community has decided
> that the contents of this repository forms the baseline for the metrics of
> this project. If a BSP in the poky repository fails to build, a release is not
> made. If a build using the poky repository starts to take a significant amount
> of more time, then a fix is implemented or the increase justified. Releases
> don't go out the door until the poky repository is happy. But, as such, it
> should be viewed as an internal project that shouldn't ever see the light of
> day, should almost not be public, and shouldn't be referred to in the quick
> start guides etc. In this light the poky repository should be something that
> only the people responsible for making releases should know about.
>
> How often do new people to this project follow the "Getting Started Guide"
> perfectly fine, then try to build an image for some board (or distro) that
> isn't part of the poky repository and fall flat on their faces? In my opinion:
> often. Why is that? It's because the Getting Started Guide and the poky
> repository haven't really taught them how to find and combine layers on their
> own; which is a very important and vital skill if someone is going to be doing
> builds with these tools. It hasn't taught them exactly what they need
> (OE/meta, BSP, distro) to build an image.
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
More information about the Openembedded-architecture
mailing list