<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 9, 2013 at 4:24 PM, Christian Betz <span dir="ltr"><<a href="mailto:christian.betz@gmail.com" target="_blank">christian.betz@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">i'm a bit late to this thread, but can I attempt to clarify the<br>
procedures? please correct me if i get something backwards.<br></blockquote><div><br></div><div style>Good that someone commented on this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the patch submission/approval/merge process generally works like so<br>
with regards to how things land in various branches:<br>
<br>
1. submit patch to mailing list and work through comments. possibly resubmit.<br>
2. patch accepted and merged into master-next (if applicable)<br></blockquote><div><br></div><div style>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. after N weeks master-next is merged into master (assuming nothing broke)<br>
4. if applicable, patch can be backported to the<br>
${current_stable_release}-next branch (i.e. dylan-next)<br>
5. after M weeks the ${current_stable_release}-next branch is merged<br>
into ${current_stable_release).<br>
<br>
N and M are typically 1 but could be more depending on the activity level.<br></blockquote><div><br></div><div style>Good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the next question is about specifically how you recommend testing<br>
master-next (I am interested in testing qt5 and vivante binaries from<br>
the latest freescale BSP)<br>
<br>
* it seems obvious enough that the meta-fsl-* projects should use master-next.<br>
* the meta-openembedded repo doesn't have a master-next branch so I<br>
assume I want master in this case.<br>
* poky also has a master-next branch and I assumed I should use<br>
that... but their appears to be a version mismatch in mesa so I am<br>
using master.<br>
**poky master has this recipe for<br>
mesa:./meta/recipes-graphics/mesa/<a href="http://mesa_9.1.3.bb" target="_blank">mesa_9.1.3.bb</a>,<br>
**but poky master-next has: ./meta/recipes-graphics/mesa/<a href="http://mesa_9.0.2.bb" target="_blank">mesa_9.0.2.bb</a></blockquote><div><br></div><div style>When working in meta-fsl-* I've been using those as master-next and all others in 'master'.</div>
<div><br></div><div style>...</div><div style>I dropped the other topic on propose as those are off-topic in this thread. Please start a new topic for it.</div></div><div><br></div>-- <br>Otavio Salvador O.S. Systems<br>
<a href="http://www.ossystems.com.br" target="_blank">http://www.ossystems.com.br</a> <a href="http://projetos.ossystems.com.br" target="_blank">http://projetos.ossystems.com.br</a><br>Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750<br>
</div></div>