On Tue, Apr 3, 2012 at 10:15 AM, Tom Rini <tom.r...@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 _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
