<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Any more comments?</p>
<p><br>
</p>
<p>I started to use stable/{branch}-next in all the contrib repos.
Poky will be constructed from oe-contrib repos.</p>
<p><br>
</p>
<p>thanks for all the feedback.</p>
<p>regards,</p>
<p>Armin<br>
</p>
<br>
<div class="moz-cite-prefix">On 11/06/2017 10:14 AM, akuster808
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:18f73e9e-6c8f-2c36-f9fc-6d6e53ef179d@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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"
moz-do-not-send="true">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">
</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" moz-do-not-send="true">Openembedded-architecture@lists.openembedded.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openembedded.org/mailman/listinfo/openembedded-architecture" moz-do-not-send="true">http://lists.openembedded.org/mailman/listinfo/openembedded-architecture</a>
</pre>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>