<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <p><br>

    </p>

    <br>

    <div class="moz-cite-prefix">On 11/06/2017 08:43 AM, Denys

      Dmytriyenko wrote:<br>

    </div>

    <blockquote type="cite" cite="mid:20171106164345.GQ9221@denix.org">

      <pre wrap="">On Fri, Nov 03, 2017 at 09:20:43AM -0700, akuster808 wrote:

</pre>

      <blockquote type="cite">

        <pre wrap="">Hello,

The problem I hope to solve is that a Maintainer can stage changes in

any branch in the contrib repos making it difficult for folks to track

their back port requests. The also makes it harder to automate any kind

of build automation.

I would like to propose a contrib naming scheme for the stable release

branches. I am thinking of the following:

stable/{version}-next or {special char}_stable/{version}-next.

Â Â  "version" is either the code name or numeric like in bitbake.

Â Â  "special char" would be used to have these branches at the top of th

list, if we wont that.

</pre>

      </blockquote>

      <pre wrap="">

I like this branch unification!

I know we discussed this at OEDEM and there was some convenience reason given, 

but can we also standardize on the tree? I.e. openembedded-core-contrib vs. 

poky-contrib?</pre>

    </blockquote>

    <br>

    The current Poky maintenance process talks about deconstructing

    "stable-next":<br>

<a class="moz-txt-link-freetext" href="https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Stable_branch_maintainers">https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Stable_branch_maintainers</a><br>

    Â <br>

    <li> Split out any bitbake changes and send them to the

      bitbake-devel mailing list (marking them with the appropriate

      stable version in the subject line e.g. [1.20])

    </li>

    <li> Split out OE-Core changes and create an

      openembedded-core-contrib branch containing them; send the cover

      letter only (marking it as such in the subject) to the

      openembedded-core mailing list.

    </li>

    <blockquote type="cite" cite="mid:20171106164345.GQ9221@denix.org">

      <pre wrap="">

</pre>

    </blockquote>

    The above has been happening viaÂ  a script Richard runs.Â  I

    personally think it the workflow should be for OE -> Yocto. This

    does add more work for the maintainer but is cleaner.Â  I did ask

    Richard to create bitbake-contrib for this purpose but am lazy as he

    uses his script ; )<br>

    <br>

    The reason I choose "stable/" branching is that the "-next" branches

    are out of sync and not being used correctly or not defined on their

    purpose. another subject for another time.<br>

    <br>

    - armin<br>

    <br>

    <blockquote type="cite" cite="mid:20171106164345.GQ9221@denix.org">

      <pre wrap="">

</pre>

      <blockquote type="cite">

        <pre wrap="">We can apply this to all OE / Yocto repos that have stable branch

maintenance process.

If we standardize on a naming scheme, We can then document this so

contributers can monitor their requests more easily. The community can

see what changes are being backport.Â  This will enable the possibility

to automate builds, etc.Â 

let me know what you think.

Kind regards,

Armin

_______________________________________________

Openembedded-architecture mailing list

<a class="moz-txt-link-abbreviated" href="mailto:Openembedded-architecture@lists.openembedded.org">Openembedded-architecture@lists.openembedded.org</a>

<a class="moz-txt-link-freetext" href="http://lists.openembedded.org/mailman/listinfo/openembedded-architecture">http://lists.openembedded.org/mailman/listinfo/openembedded-architecture</a>

</pre>

      </blockquote>

    </blockquote>

    <br>

  </body>

</html>