Merge protocol - proposal

Merge protocol - proposal

[Daiane Angolini]

I know I'm completely late about "Merge Protocol Proposal" I had said I 
would send it 2 weeks after the release. And I do have a lot of excuses 
(or runarounds), but it doesn't matter.

Please, see below my proposal for merge protocol. I hope we can get at 
least 10 people "voting" on this topic.

Please, let me know what you think.


Regards,
Daiane

*Development branch*

Any development or bug fix MUST be done over master at first. If you 
need any bugfix on your stable branch, you MUST fix the same bug on 
master, except when it is not applicable to master, for example (e.g: 
newer BSP release has fixed the bug).

The standard review window for new features will be of one week, unless 
cover letter expands this period. New patch versions expands the review 
window by one day.

The standard review window for bugfixes is one day, unless cover letter 
expands this period. New patch versions expands the review window by one 
day.

In case the patch has no comment, it will be applied after the review 
window.


*Stable branch*

No new feature will be accepted

Any bugfix backported to any stable branch will have one week for 
review, unless cover letter expands this period.

In case of no comment, the patch will be merged in stable-next branch 
(dylan-next, danny-next).

Every friday any patch on stable-next branch will be merged on stable 
branch, unless any comment or bug reported. The patches sent to 
stable-next must have been applied in master before (unless not applicable).

Re: Merge protocol - proposal

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]

On Tue, Jun 4, 2013 at 3:26 PM, Daiane Angolini <
daiane.angolini@freescale.com> wrote:

> *Development branch*
>
> Any development or bug fix MUST be done over master at first. If you need
> any bugfix on your stable branch, you MUST fix the same bug on master,
> except when it is not applicable to master, for example (e.g: newer BSP
> release has fixed the bug).
>
> The standard review window for new features will be of one week, unless
> cover letter expands this period. New patch versions expands the review
> window by one day.
>
> The standard review window for bugfixes is one day, unless cover letter
> expands this period. New patch versions expands the review window by one
> day.
>
> In case the patch has no comment, it will be applied after the review
> window.
>
>
> *Stable branch*
>
> No new feature will be accepted
>
> Any bugfix backported to any stable branch will have one week for review,
> unless cover letter expands this period.
>
> In case of no comment, the patch will be merged in stable-next branch
> (dylan-next, danny-next).
>
> Every friday any patch on stable-next branch will be merged on stable
> branch, unless any comment or bug reported. The patches sent to stable-next
> must have been applied in master before (unless not applicable).
>

+1

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 2037 bytes --]

Re: Merge protocol - proposal

[Christian Betz]

[-- Attachment #1: Type: text/plain, Size: 6341 bytes --]

i'm a bit late to this thread, but can I attempt to clarify the
procedures? please correct me if i get something backwards.

the patch submission/approval/merge process generally works like so
with regards to how things land in various branches:

1. submit patch to mailing list and work through comments. possibly resubmit.
2. patch accepted and merged into master-next (if applicable)
3. after N weeks master-next is merged into master (assuming nothing broke)
4. if applicable, patch can be backported to the
${current_stable_release}-next branch (i.e. dylan-next)
5. after M weeks the ${current_stable_release}-next branch is merged
into ${current_stable_release).

N and M are typically 1 but could be more depending on the activity level.

the next question is about specifically how you recommend testing
master-next (I am interested in testing qt5 and vivante binaries from
the latest freescale BSP)

* it seems obvious enough that the meta-fsl-* projects should use master-next.
* the meta-openembedded repo doesn't have a master-next branch so I
assume I want master in this case.
* poky also has a master-next branch and I assumed I should use
that... but their appears to be a version mismatch in mesa so I am
using master.
**poky master has this recipe for
mesa:./meta/recipes-graphics/mesa/mesa_9.1.3.bb,
**but poky master-next has: ./meta/recipes-graphics/mesa/mesa_9.0.2.bb

the manifest.xml I am using is at the end of this email. basically: I
run "repo sync" and then bitbake fsl-image-test. currently this fails
trying to build libglu. (with an ld error: cannot find -lGL). this can
be avoided by removing "tools-testapps" from fsl-image-test.bb, but I
don't think that is a desirable solution.  i didn't starting really
digging yet but i'm pretty sure it should be using GLES, if that's
possible.

finally: is it an issue that we can't find a way to package both the
framebuffer and x11 gpu binaries with in the same distro? is there a
way that *both* can be installed one system or is that too difficult
with the binaries we get from freescale/vivante? (I recall this was
discussed briefly. was a conclusion reached?)

AFAICT the only ways to adjust DISTRO_FEATURES and remove x11 are to
explictly set DISTRO_FEATURES, create your own distro based on poky,
or use a technique like this:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/user_features.bbclass.
I'm going to try the latter in order to build qt5 EGL framebuffer
backend test images.

--christian

Build Configuration:
BB_VERSION        = "1.19.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS        = "arm-poky-linux-gnueabi"
MACHINE           = "imx6qsabresd"
DISTRO            = "poky"
DISTRO_VERSION    = "1.4+snapshot-20130609"
TUNE_FEATURES     = "armv7a vfp neon"
TARGET_FPU        = "vfp-neon"
meta
meta-yocto        = "(nobranch):7bf5c38e0f8bed9295f46773ade5336ec41044f6"
meta-oe           = "(nobranch):72ddf338d848d613855c96259fcf9ffb57e98010"
meta-fsl-arm      = "(nobranch):fd04653be23c44944ee161661712683cf7876ab6"
meta-fsl-arm-extra = "(nobranch):4961d9bdf6aaa2377d788363ac5a3714861ac891"
meta-fsl-demos    = "(nobranch):677ce915e8fbea322a4f7ed7df65a705ee1e9edb"

<?xml version="1.0" encoding="UTF-8"?>
<manifest>

  <default sync-j="4"/>

  <remote fetch="git://git.yoctoproject.org" name="yocto"/>
  <remote fetch="git://github.com/Freescale" name="freescale"/>
  <remote fetch="git://git.openembedded.org" name="oe"/>

  <project remote="yocto" revision="master" name="poky" path="sources/poky"/>
  <project remote="yocto" revision="master-next" name="meta-fsl-arm"
path="sources/meta-fsl-arm"/>

  <project remote="oe" revision="master" name="meta-openembedded"
path="sources/meta-openembedded"/>

  <project remote="freescale" revision="dylan"
name="fsl-community-bsp-base" path="sources/base">
        <copyfile dest="README" src="README"/>
        <copyfile dest="setup-environment" src="setup-environment"/>
  </project>

  <project remote="freescale" revision="master-next"
name="meta-fsl-arm-extra" path="sources/meta-fsl-arm-extra"/>
  <project remote="freescale" revision="master-next"
name="meta-fsl-demos" path="sources/meta-fsl-demos"/>

</manifest>

On Wed, Jun 5, 2013 at 8:21 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>
>
>
> On Tue, Jun 4, 2013 at 3:26 PM, Daiane Angolini
> <daiane.angolini@freescale.com> wrote:
>>
>> *Development branch*
>>
>> Any development or bug fix MUST be done over master at first. If you need
>> any bugfix on your stable branch, you MUST fix the same bug on master,
>> except when it is not applicable to master, for example (e.g: newer BSP
>> release has fixed the bug).
>>
>> The standard review window for new features will be of one week, unless
>> cover letter expands this period. New patch versions expands the review
>> window by one day.
>>
>> The standard review window for bugfixes is one day, unless cover letter
>> expands this period. New patch versions expands the review window by one
>> day.
>>
>> In case the patch has no comment, it will be applied after the review
>> window.
>>
>>
>> *Stable branch*
>>
>> No new feature will be accepted
>>
>> Any bugfix backported to any stable branch will have one week for review,
>> unless cover letter expands this period.
>>
>> In case of no comment, the patch will be merged in stable-next branch
>> (dylan-next, danny-next).
>>
>> Every friday any patch on stable-next branch will be merged on stable
>> branch, unless any comment or bug reported. The patches sent to stable-next
>> must have been applied in master before (unless not applicable).
>
>
> +1
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://projetos.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>



-- 
"the new garbage collector will be an arena-based, quad-color
incremental, generational, non-copying, high-speed, cache-optimized
garbage collector" -- LuaJIT Roadmap

[-- Attachment #2: log.do_compile --]
[-- Type: application/octet-stream, Size: 13068 bytes --]

DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
DEBUG: Executing shell function do_compile
NOTE: make -j 6
./arm-poky-linux-gnueabi-libtool  --tag=CXX   --mode=link arm-poky-linux-gnueabi-g++  -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon --sysroot=/mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd -I/mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd/usr/include/libdrm   -Wall -fvisibility=hidden -O2 -pipe -g -feliminate-unused-debug-types -fpermissive -fvisibility-inlines-hidden -version-number 1:3:1 -no-undefined -export-symbols-regex '^glu' -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o libGLU.la -rpath /usr/lib src/libutil/error.lo src/libutil/glue.lo src/libutil/mipmap.lo src/libutil/project.lo src/libutil/quad.lo src/libutil/registry.lo src/libtess/dict.lo src/libtess/geom.lo src/libtess/memalloc.lo src/libtess/mesh.lo src/libtess/normal.lo src/libtess/priorityq.lo src/libtess/render.lo src/libtess/sweep.lo src/libtess/tess.lo src/libtess/tessmono.lo src/libnurbs/interface/bezierEval.lo src/libnurbs/interface/bezierPatch.lo src/libnurbs/interface/bezierPatchMesh.lo src/libnurbs/interface/glcurveval.lo src/libnurbs/interface/glinterface.lo src/libnurbs/interface/glrenderer.lo src/libnurbs/interface/glsurfeval.lo src/libnurbs/interface/incurveeval.lo src/libnurbs/interface/insurfeval.lo src/libnurbs/internals/arc.lo src/libnurbs/internals/arcsorter.lo src/libnurbs/internals/arctess.lo src/libnurbs/internals/backend.lo src/libnurbs/internals/basiccrveval.lo src/libnurbs/internals/basicsurfeval.lo src/libnurbs/internals/bin.lo src/libnurbs/internals/bufpool.lo src/libnurbs/internals/cachingeval.lo src/libnurbs/internals/ccw.lo src/libnurbs/internals/coveandtiler.lo src/libnurbs/internals/curve.lo src/libnurbs/internals/curvelist.lo src/libnurbs/internals/curvesub.lo src/libnurbs/internals/dataTransform.lo src/libnurbs/internals/displaylist.lo src/libnurbs/internals/flist.lo src/libnurbs/internals/flistsorter.lo src/libnurbs/internals/hull.lo src/libnurbs/internals/intersect.lo src/libnurbs/internals/knotvector.lo src/libnurbs/internals/mapdesc.lo src/libnurbs/internals/mapdescv.lo src/libnurbs/internals/maplist.lo src/libnurbs/internals/mesher.lo src/libnurbs/internals/monoTriangulationBackend.lo src/libnurbs/internals/monotonizer.lo src/libnurbs/internals/mycode.lo src/libnurbs/internals/nurbsinterfac.lo src/libnurbs/internals/nurbstess.lo src/libnurbs/internals/patch.lo src/libnurbs/internals/patchlist.lo src/libnurbs/internals/quilt.lo src/libnurbs/internals/reader.lo src/libnurbs/internals/renderhints.lo src/libnurbs/internals/slicer.lo src/libnurbs/internals/sorter.lo src/libnurbs/internals/splitarcs.lo src/libnurbs/internals/subdivider.lo src/libnurbs/internals/tobezier.lo src/libnurbs/internals/trimline.lo src/libnurbs/internals/trimregion.lo src/libnurbs/internals/trimvertpool.lo src/libnurbs/internals/uarray.lo src/libnurbs/internals/varray.lo src/libnurbs/nurbtess/directedLine.lo src/libnurbs/nurbtess/gridWrap.lo src/libnurbs/nurbtess/monoChain.lo src/libnurbs/nurbtess/monoPolyPart.lo src/libnurbs/nurbtess/monoTriangulation.lo src/libnurbs/nurbtess/partitionX.lo src/libnurbs/nurbtess/partitionY.lo src/libnurbs/nurbtess/polyDBG.lo src/libnurbs/nurbtess/polyUtil.lo src/libnurbs/nurbtess/primitiveStream.lo src/libnurbs/nurbtess/quicksort.lo src/libnurbs/nurbtess/rectBlock.lo src/libnurbs/nurbtess/sampleComp.lo src/libnurbs/nurbtess/sampleCompBot.lo src/libnurbs/nurbtess/sampleCompRight.lo src/libnurbs/nurbtess/sampleCompTop.lo src/libnurbs/nurbtess/sampleMonoPoly.lo src/libnurbs/nurbtess/sampledLine.lo src/libnurbs/nurbtess/searchTree.lo -lGL   
arm-poky-linux-gnueabi-libtool: link: rm -fr  .libs/libGLU.exp
arm-poky-linux-gnueabi-libtool: link: arm-poky-linux-gnueabi-nm  src/libutil/.libs/error.o src/libutil/.libs/glue.o src/libutil/.libs/mipmap.o src/libutil/.libs/project.o src/libutil/.libs/quad.o src/libutil/.libs/registry.o src/libtess/.libs/dict.o src/libtess/.libs/geom.o src/libtess/.libs/memalloc.o src/libtess/.libs/mesh.o src/libtess/.libs/normal.o src/libtess/.libs/priorityq.o src/libtess/.libs/render.o src/libtess/.libs/sweep.o src/libtess/.libs/tess.o src/libtess/.libs/tessmono.o src/libnurbs/interface/.libs/bezierEval.o src/libnurbs/interface/.libs/bezierPatch.o src/libnurbs/interface/.libs/bezierPatchMesh.o src/libnurbs/interface/.libs/glcurveval.o src/libnurbs/interface/.libs/glinterface.o src/libnurbs/interface/.libs/glrenderer.o src/libnurbs/interface/.libs/glsurfeval.o src/libnurbs/interface/.libs/incurveeval.o src/libnurbs/interface/.libs/insurfeval.o src/libnurbs/internals/.libs/arc.o src/libnurbs/internals/.libs/arcsorter.o src/libnurbs/internals/.libs/arctess.o src/libnurbs/internals/.libs/backend.o src/libnurbs/internals/.libs/basiccrveval.o src/libnurbs/internals/.libs/basicsurfeval.o src/libnurbs/internals/.libs/bin.o src/libnurbs/internals/.libs/bufpool.o src/libnurbs/internals/.libs/cachingeval.o src/libnurbs/internals/.libs/ccw.o src/libnurbs/internals/.libs/coveandtiler.o src/libnurbs/internals/.libs/curve.o src/libnurbs/internals/.libs/curvelist.o src/libnurbs/internals/.libs/curvesub.o src/libnurbs/internals/.libs/dataTransform.o src/libnurbs/internals/.libs/displaylist.o src/libnurbs/internals/.libs/flist.o src/libnurbs/internals/.libs/flistsorter.o src/libnurbs/internals/.libs/hull.o src/libnurbs/internals/.libs/intersect.o src/libnurbs/internals/.libs/knotvector.o src/libnurbs/internals/.libs/mapdesc.o src/libnurbs/internals/.libs/mapdescv.o src/libnurbs/internals/.libs/maplist.o src/libnurbs/internals/.libs/mesher.o src/libnurbs/internals/.libs/monoTriangulationBackend.o src/libnurbs/internals/.libs/monotonizer.o src/libnurbs/internals/.libs/mycode.o src/libnurbs/internals/.libs/nurbsinterfac.o src/libnurbs/internals/.libs/nurbstess.o src/libnurbs/internals/.libs/patch.o src/libnurbs/internals/.libs/patchlist.o src/libnurbs/internals/.libs/quilt.o src/libnurbs/internals/.libs/reader.o src/libnurbs/internals/.libs/renderhints.o src/libnurbs/internals/.libs/slicer.o src/libnurbs/internals/.libs/sorter.o src/libnurbs/internals/.libs/splitarcs.o src/libnurbs/internals/.libs/subdivider.o src/libnurbs/internals/.libs/tobezier.o src/libnurbs/internals/.libs/trimline.o src/libnurbs/internals/.libs/trimregion.o src/libnurbs/internals/.libs/trimvertpool.o src/libnurbs/internals/.libs/uarray.o src/libnurbs/internals/.libs/varray.o src/libnurbs/nurbtess/.libs/directedLine.o src/libnurbs/nurbtess/.libs/gridWrap.o src/libnurbs/nurbtess/.libs/monoChain.o src/libnurbs/nurbtess/.libs/monoPolyPart.o src/libnurbs/nurbtess/.libs/monoTriangulation.o src/libnurbs/nurbtess/.libs/partitionX.o src/libnurbs/nurbtess/.libs/partitionY.o src/libnurbs/nurbtess/.libs/polyDBG.o src/libnurbs/nurbtess/.libs/polyUtil.o src/libnurbs/nurbtess/.libs/primitiveStream.o src/libnurbs/nurbtess/.libs/quicksort.o src/libnurbs/nurbtess/.libs/rectBlock.o src/libnurbs/nurbtess/.libs/sampleComp.o src/libnurbs/nurbtess/.libs/sampleCompBot.o src/libnurbs/nurbtess/.libs/sampleCompRight.o src/libnurbs/nurbtess/.libs/sampleCompTop.o src/libnurbs/nurbtess/.libs/sampleMonoPoly.o src/libnurbs/nurbtess/.libs/sampledLine.o src/libnurbs/nurbtess/.libs/searchTree.o   | sed -n -e 's/^.*[	 ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[	 ][	 ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | /bin/sed 's/.* //' | sort | uniq > .libs/libGLU.exp
arm-poky-linux-gnueabi-libtool: link: /bin/grep -E -e "^glu" ".libs/libGLU.exp" > ".libs/libGLU.expT"
arm-poky-linux-gnueabi-libtool: link: mv -f ".libs/libGLU.expT" ".libs/libGLU.exp"
arm-poky-linux-gnueabi-libtool: link: arm-poky-linux-gnueabi-g++  -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon --sysroot=/mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd  -fPIC -DPIC -shared -nostdlib /mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd/usr/lib/crti.o /mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd/usr/lib/arm-poky-linux-gnueabi/4.7.2/crtbeginS.o  src/libutil/.libs/error.o src/libutil/.libs/glue.o src/libutil/.libs/mipmap.o src/libutil/.libs/project.o src/libutil/.libs/quad.o src/libutil/.libs/registry.o src/libtess/.libs/dict.o src/libtess/.libs/geom.o src/libtess/.libs/memalloc.o src/libtess/.libs/mesh.o src/libtess/.libs/normal.o src/libtess/.libs/priorityq.o src/libtess/.libs/render.o src/libtess/.libs/sweep.o src/libtess/.libs/tess.o src/libtess/.libs/tessmono.o src/libnurbs/interface/.libs/bezierEval.o src/libnurbs/interface/.libs/bezierPatch.o src/libnurbs/interface/.libs/bezierPatchMesh.o src/libnurbs/interface/.libs/glcurveval.o src/libnurbs/interface/.libs/glinterface.o src/libnurbs/interface/.libs/glrenderer.o src/libnurbs/interface/.libs/glsurfeval.o src/libnurbs/interface/.libs/incurveeval.o src/libnurbs/interface/.libs/insurfeval.o src/libnurbs/internals/.libs/arc.o src/libnurbs/internals/.libs/arcsorter.o src/libnurbs/internals/.libs/arctess.o src/libnurbs/internals/.libs/backend.o src/libnurbs/internals/.libs/basiccrveval.o src/libnurbs/internals/.libs/basicsurfeval.o src/libnurbs/internals/.libs/bin.o src/libnurbs/internals/.libs/bufpool.o src/libnurbs/internals/.libs/cachingeval.o src/libnurbs/internals/.libs/ccw.o src/libnurbs/internals/.libs/coveandtiler.o src/libnurbs/internals/.libs/curve.o src/libnurbs/internals/.libs/curvelist.o src/libnurbs/internals/.libs/curvesub.o src/libnurbs/internals/.libs/dataTransform.o src/libnurbs/internals/.libs/displaylist.o src/libnurbs/internals/.libs/flist.o src/libnurbs/internals/.libs/flistsorter.o src/libnurbs/internals/.libs/hull.o src/libnurbs/internals/.libs/intersect.o src/libnurbs/internals/.libs/knotvector.o src/libnurbs/internals/.libs/mapdesc.o src/libnurbs/internals/.libs/mapdescv.o src/libnurbs/internals/.libs/maplist.o src/libnurbs/internals/.libs/mesher.o src/libnurbs/internals/.libs/monoTriangulationBackend.o src/libnurbs/internals/.libs/monotonizer.o src/libnurbs/internals/.libs/mycode.o src/libnurbs/internals/.libs/nurbsinterfac.o src/libnurbs/internals/.libs/nurbstess.o src/libnurbs/internals/.libs/patch.o src/libnurbs/internals/.libs/patchlist.o src/libnurbs/internals/.libs/quilt.o src/libnurbs/internals/.libs/reader.o src/libnurbs/internals/.libs/renderhints.o src/libnurbs/internals/.libs/slicer.o src/libnurbs/internals/.libs/sorter.o src/libnurbs/internals/.libs/splitarcs.o src/libnurbs/internals/.libs/subdivider.o src/libnurbs/internals/.libs/tobezier.o src/libnurbs/internals/.libs/trimline.o src/libnurbs/internals/.libs/trimregion.o src/libnurbs/internals/.libs/trimvertpool.o src/libnurbs/internals/.libs/uarray.o src/libnurbs/internals/.libs/varray.o src/libnurbs/nurbtess/.libs/directedLine.o src/libnurbs/nurbtess/.libs/gridWrap.o src/libnurbs/nurbtess/.libs/monoChain.o src/libnurbs/nurbtess/.libs/monoPolyPart.o src/libnurbs/nurbtess/.libs/monoTriangulation.o src/libnurbs/nurbtess/.libs/partitionX.o src/libnurbs/nurbtess/.libs/partitionY.o src/libnurbs/nurbtess/.libs/polyDBG.o src/libnurbs/nurbtess/.libs/polyUtil.o src/libnurbs/nurbtess/.libs/primitiveStream.o src/libnurbs/nurbtess/.libs/quicksort.o src/libnurbs/nurbtess/.libs/rectBlock.o src/libnurbs/nurbtess/.libs/sampleComp.o src/libnurbs/nurbtess/.libs/sampleCompBot.o src/libnurbs/nurbtess/.libs/sampleCompRight.o src/libnurbs/nurbtess/.libs/sampleCompTop.o src/libnurbs/nurbtess/.libs/sampleMonoPoly.o src/libnurbs/nurbtess/.libs/sampledLine.o src/libnurbs/nurbtess/.libs/searchTree.o   -lGL -L/mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/x86_64-linux/usr/lib/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2 -L/mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd/lib -L/mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd/usr/lib/arm-poky-linux-gnueabi/4.7.2 -L/mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd/usr/lib /mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd/usr/lib/libstdc++.so -lm -lc -lgcc_s /mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd/usr/lib/arm-poky-linux-gnueabi/4.7.2/crtendS.o /mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd/usr/lib/crtn.o  -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon --sysroot=/mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/imx6qsabresd -O2 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed   -Wl,-soname -Wl,libGLU.so.1 -Wl,-retain-symbols-file -Wl,.libs/libGLU.exp -o .libs/libGLU.so.1.3.1
/mnt/arm/fsl-community-bsp/build-master-next/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find -lGL
collect2: error: ld returned 1 exit status
make: *** [libGLU.la] Error 1
ERROR: oe_runmake failed
ERROR: Function failed: do_compile (log file is located at /mnt/arm/fsl-community-bsp/build-master-next/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/libglu/2_9.0.0-0/temp/log.do_compile.5104)

Re: Merge protocol - proposal

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

On Sun, Jun 9, 2013 at 4:24 PM, Christian Betz <christian.betz@gmail.com>wrote:

> i'm a bit late to this thread, but can I attempt to clarify the
> procedures? please correct me if i get something backwards.
>

Good that someone commented on this.


> the patch submission/approval/merge process generally works like so
> with regards to how things land in various branches:
>
> 1. submit patch to mailing list and work through comments. possibly
> resubmit.
> 2. patch accepted and merged into master-next (if applicable)
>

The step 2 is skipped in cases like bbappend update or critical bugfixes
(as we had for example in the kernel oops when using NAPI for mx5, for
example).


> 3. after N weeks master-next is merged into master (assuming nothing broke)
> 4. if applicable, patch can be backported to the
> ${current_stable_release}-next branch (i.e. dylan-next)
> 5. after M weeks the ${current_stable_release}-next branch is merged
> into ${current_stable_release).
>
> N and M are typically 1 but could be more depending on the activity level.
>

Good.


> the next question is about specifically how you recommend testing
> master-next (I am interested in testing qt5 and vivante binaries from
> the latest freescale BSP)
>
> * it seems obvious enough that the meta-fsl-* projects should use
> master-next.
> * the meta-openembedded repo doesn't have a master-next branch so I
> assume I want master in this case.
> * poky also has a master-next branch and I assumed I should use
> that... but their appears to be a version mismatch in mesa so I am
> using master.
> **poky master has this recipe for
> mesa:./meta/recipes-graphics/mesa/mesa_9.1.3.bb,
> **but poky master-next has: ./meta/recipes-graphics/mesa/mesa_9.0.2.bb


When working in meta-fsl-* I've been using those as master-next and all
others in 'master'.

...
I dropped the other topic on propose as those are off-topic in this thread.
Please start a new topic for it.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 3337 bytes --]

Re: Merge protocol - proposal

[Daiane Angolini]

On 06/04/2013 03:26 PM, Daiane Angolini wrote:
> Please, see below my proposal for merge protocol. I hope we can get at
> least 10 people "voting" on this topic.
>
> Please, let me know what you think.


I was not able to get 10 people voting on this.

It think this topic simple doesn't matter. So let's keep doing merge as 
needed. Use master-next as needed.

If, in future, we need to setup a new merge protocol, we can come back 
to this point.


Regards,
-- 
Daiane