On 03/30/2012 06:37 PM, Koen Kooi wrote: > > Op 30 mrt. 2012, om 18:21 heeft Darren Hart het volgende geschreven: >> >> So that brings us back to what does it mean for Angstrom to be a Yocto >> Project project I guess? >> >> In my very humble opinion (really), it still makes sense to build >> Angstrom with the components in the poky repository as part of a Yocto >> Project release. I understand that there is resistance to this idea. > > Yes, it would force angstrom developers to ignore upstream and work on > downstream projects
That's an understandable concern. If I were a casual observer, I would expect every project identifying itself with the Yocto Project to interoperate with eachother at each release point. I would imagine that Angstrom developers would continue their feature development with the upstreams of bitbake and oe-core. As a Yocto Project release occurs (or shortly after, as is the case with many BSPs) I would then expect (again as a casual observer) that some effort went into ensuring some version of Angstrom works with the release of the poky repository. You've mentioned preferring to do this with set versions of bitbake and oe-core. Do oe-core and bitbake maintain stable branches? I didn't think they did. This makes it difficult to stabilize a release, and poky serves this purpose well in my opinion. I'm going to stop going down this path though as the policies surrounding this aren't clear to me and would be better coming from others (RP or Chris for example). Without this, people working with "The Yocto Project" are back to using different versions of bitbake and oe-core depending on which distribution or BSP they are building, and we ultimately end up where we started with unsolvable dependency chains and people passing around fixup patches for this or that issue. > or as I will label them from now on: forks. > >> Angstrom has been independent from poky and the Yocto Project in the >> past and I can understand not wanting to lose some of that >> individuality. However, too much individuality breeds chaos and >> fragmentation. > > I will draw a line in the sand here and say: Forcing people to ignore > upstream (oe-core/bitbake) and force a fork down their throats > breeds chaos and fragmentation. Don't be so dramatic Koen :-) Everybody involved knows the bitbake and oe-core in the poky repository are not forks, at least not in the sense you portray here. They are snapshots with the same maintainer (or subset of maintainers). They are no more "forks" than the stable Linux kernels maintained by Greg KH are forks of Linus' kernel. I won't presume to make a statement of policy regarding submitting patches against poky that aren't also destined for oe-core or bitbake as well, but I personally wouldn't deign to submit such a patch for fear of the wrath of Purdie (and a flame or two from a certain dutchman ;-). > I will again refer to the agreement between the OE community and yocto > for doing the 'merge'. > > If you people (all speaking personally of course) really think poky is the > only > way to go, then please close down and remove the oe-core and bitbake repos. I see poky as collecting and integrating these projects into a known-to-work-well-together snapshot. I suppose this is similar to what the Angstrom setup scripts do, except the fetching is done for you in poky instead of after the fact in Angstrom. I think this is a more accurate description than calling them forks. As I said, this was my personal opinion. RP and Jefro have both expressed much looser views on what it should mean to be part of the Yocto Project (and each carry more weight in this discussion than I). So please don't use my comments as a reason not to pursue becoming "part of the Yocto Project". As I said, I do not speak in any official capacity as to what constitutes criteria. "We're just talking here" :-) OK... time for more medication and some sleep... ugh. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
