[oe] [yocto] [Openembedded-architecture] [RFC] stable branch naming scheme

akuster808 akuster808 at gmail.com
Thu Nov 9 19:43:31 UTC 2017


Any more comments?


I started to use stable/{branch}-next in all the contrib repos. Poky
will be constructed from oe-contrib repos.


thanks for all the feedback.

regards,

Armin


On 11/06/2017 10:14 AM, akuster808 wrote:
>
>
>
> On 11/06/2017 08:43 AM, Denys Dmytriyenko wrote:
>> On Fri, Nov 03, 2017 at 09:20:43AM -0700, akuster808 wrote:
>>> 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.
>> 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?
>
> The current Poky maintenance process talks about deconstructing
> "stable-next":
> https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Stable_branch_maintainers
>  
> # 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])
> # 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.
> 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 ; )
>
> 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.
>
> - armin
>
>>> 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
>>> Openembedded-architecture at lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>




More information about the Openembedded-devel mailing list