[meta-freescale] Merge protocol - proposal

Sun Jun 9 12:24:35 PDT 2013

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 at ossystems.com.br> wrote:
>
>
>
> On Tue, Jun 4, 2013 at 3:26 PM, Daiane Angolini
> <daiane.angolini at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.do_compile
Type: application/octet-stream
Size: 13067 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20130609/996dcb0b/attachment.obj>