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-architect...@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto