[yocto] Moving angstrom under the yocto banner

[Tom Rini]

On Fri, Mar 30, 2012 at 07:27:16PM -0700, Darren Hart wrote:

[snip]
> 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).

Again, the intention of poky the repository is not intended to have its
own changes.  oe-core will have a branch to go along with this release,
just like meta-oe, meta-ti, meta-fsl-arm, meta-fsl-ppc, meta-intel and
so forth.  Richard has even been (from how the branch layout looks) been
keeping master stable and doing master-next for things that will go in
post release.

I think at this point Richard (sorry!) really, really needs to find the
time to make poky the distro be a separate layer and Yocto adopt some
form of tooling, perhaps Angstrom's setup scripts with a little bit of
abstraction, to replace the conglomerate repository and stop some of the
confusion about repository directionality (and maybe move "I need to
resurrect idea X into a branch in upstream).  This could even be done as
part of Angstrom moving under the umbrella and one of the mutual
benefits :)

> 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.

Then perhaps non-SCM blobs should be part of a Yocto Project release.
The point is that poky the repository is NOT an upstream for anything
other than poky the distro specific things.`

> > 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 ;-).

Yes, you the day to day developer understand the relationship between
bitbake, oe-core and poky the distro within poky the repository.  To the
casual or new developer it's not clear because it's not done with git
submodules or repo or other standard multi-git-repos-in-a-single-dir
tools.  It's just manual merge.

> > 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.

So lets be clear.  poky the repository is a collection of exiting
branches or tags from other projects, done as a "lets make this easy on
new / casual users".  So why should Angstrom be forced to include poky
the repository in it's work-flow when the exact same results, excluding
poky the distro, can be achieved by working upstream?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20120402/c417f0cc/attachment.pgp>