Re: Moving angstrom under the yocto banner

[Chris Larson <clarson@kergoth.com>]

On Tue, Apr 3, 2012 at 10:15 AM, Tom Rini <tom.rini@gmail.com> wrote:
> On Tue, Apr 03, 2012 at 10:08:44AM -0700, Darren Hart wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> On 04/03/2012 09:44 AM, Martin Jansa wrote:
>> > On Tue, Apr 03, 2012 at 09:32:27AM -0700, Darren Hart wrote:
>> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> >> On 04/03/2012 09:25 AM, Martin Jansa wrote:
>> >>> On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote:
>> >>>> -----BEGIN PGP SIGNED MESSAGE----- Clear reproducible
>> >>>> testing results. Whether or not a pair of git clones and some
>> >>>> tinkering can result in the same thing as a poky repository
>> >>>> or not isn't relevant in my opinion. I believe that we need a
>> >>>> consistent mode of validating support for a Yocto Project X.Y
>> >>>> release. Now if that is accomplished by building with the
>> >>>> poky repository of the same vintage or by running some script
>> >>>> that pulls the right bits together independently.... I
>> >>>> honestly don't care, but I do think it should be consistent.
>> >>>
>> >>> so teach setup script something like: poky.sh checkout X.Y
>> >>> (which checkouts whatever parts are needed for X.Y) poky.sh
>> >>> update X.Y (dtto)
>> >>>
>> >>> Which creates the same structure like poky repository has, but
>> >>> by checkouting upstream repositories or using submodules or
>> >>> whatever.
>> >>>
>> >>> That's what oebb.sh and SHR makefile does for master/shr HEADs,
>> >>> but can be extended do it for particular version too.
>> >>>
>> >>
>> >>
>> >> This is certainly doable, but it doesn't address the
>> >> stabilization buffer poky provides that I mentioned.
>> >
>> > And is it? OE @ ~ $ diff -rq openembedded-core/ projects/poky/ |
>> > grep -v '\.git' Files openembedded-core/README and
>> > projects/poky/README differ Only in projects/poky/:
>> > README.hardware Only in projects/poky/: bitbake Only in
>> > openembedded-core/: dev Only in projects/poky/: documentation Only
>> > in openembedded-core/meta/conf: bblayers.conf.sample Only in
>> > openembedded-core/meta/conf: local.conf.sample Only in
>> > openembedded-core/meta/conf: local.conf.sample.extended Only in
>> > openembedded-core/meta/conf: site.conf.sample Only in
>> > projects/poky/: meta-yocto Only in projects/poky/scripts: lib Files
>> > openembedded-core/scripts/oe-setup-builddir and
>> > projects/poky/scripts/oe-setup-builddir differ Only in
>> > projects/poky/scripts: yocto-bsp Only in projects/poky/scripts:
>> > yocto-kernel
>> >
>> > OE @ ~ $ diff -rq projects/bitbake/ projects/poky/bitbake/ | grep
>> > -v '\.git' Only in projects/bitbake/: MANIFEST.in Only in
>> > projects/bitbake/: TODO Only in projects/poky/bitbake/bin:
>> > bitbake-runtask Only in projects/bitbake/: classes Only in
>> > projects/bitbake/: conf Only in projects/bitbake/lib/bb: fetch Only
>> > in projects/poky/bitbake/lib/bb: shell.py Only in
>> > projects/bitbake/: setup.py
>> >
>> > Those changes doesn't look like stabilization buffer.. which is
>> > fine we don't need bigger diff between oe-core repo and poky copy,
>> > smaller would be nice.
>> >
>> > And "dangerous" changes are stopped to oe-core AFAIK, see e.g. my
>> > 13 pending patches...
>>
>> I expect the buffer to be empty at times. Hopefully *MOST* of the time.
>
> I really think what you're calling a stabilization buffer is what others
> of us see when we branch the repo(s) we're working on until we're happy
> with the changes.

I really don't see what the issue is here. If you want a stable
branch, we can look into creating such a thing upstream, though I'm
personally of the opinion that master should remain release-quality,
and make better use of feature branches, potentially a
next/integration branch for forthcoming features, than trying to
cherry pick onto a "stable" branch. There's nothing poky's structure
provides that can't also be provided via branching policy in the
individual repositories.
-- 
Christopher Larson