[RFC] stable branch naming scheme

[RFC] stable branch naming scheme

[akuster808]

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.


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

Re: [Openembedded-architecture] [RFC] stable branch naming scheme

[Denys Dmytriyenko]

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?


> 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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] [RFC] stable branch naming scheme

[akuster808]

[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]



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@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


[-- Attachment #2: Type: text/html, Size: 3897 bytes --]

Re: [yocto] [Openembedded-architecture] [RFC] stable branch naming scheme

[akuster808]

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@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] [RFC] stable branch naming scheme

[akuster808]

[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]

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@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>


[-- Attachment #2: Type: text/html, Size: 4635 bytes --]

Re: [yocto] [Openembedded-architecture] [RFC] stable branch naming scheme

[akuster808]

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@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>