[yocto] release management

[Chris Z.]

Hi,

Regarding submodule for layers. This is good when no one beside you use it.
Especially  with yocto layers. But when dev starts to use it. You or other
support team will be faced against wall of problems with basic
understanding of git submodules and index. But google starts to invest some
funds in submodules instead repo usage. So it can be a game changer in
favor of git submodules.

>From own experience (dev team of 80 persons) we decided to leave submodules
in favor of repo tool. But we had the same conclusion at first. Why to use
other tool were git provides submodules. Further development and expansion
of layers are pro the repo tool manifest file. But that is from my own exp.
And it was good change.

Br,
Chris Z

15.08.2017 15:16 "Joshua Watt" <jpewhacker at gmail.com> napisał(a):

> On Tue, 2017-08-15 at 09:25 +0200, Mike Looijmans wrote:
> > On 14-08-17 21:10, Gunnar Andersson wrote:
> > >
> > > Hey Russell
> > >
> > > I don't claim to be an authority on best practices but I will share
> > > some
> > > thoughts.
> > >
> > > On Sun, 2017-08-13 at 06:58 -0400, Russell Peterson wrote:
> > > > Hello.
> > > >
> > > > As I learn more about yocto and more importantly gain practical
> > > > experience
> > > > with it I have started to think about my release structure.  Is
> > > > there a
> > > > “best practices” document or something like that that speaks to
> > > > this?
> > > > For example, how does everyone deal with “external” meta layer
> > > > dependencies?  My software uses poky and meta-openembedded, of
> > > > course.
> > >
> > > We simply use a parent project [1] that includes git submodules,
> > > one per
> > > yocto layer.  I'm of the opinion that if git (only) can be used,
> > > why
> > > introduce other tools?   But it requires you to learn and master
> > > that
> > > feature.
> > >
> >
> > We arrived at exactly the same setup. One parent repository that
> > contains the
> > project-unique recipes, and submodules for the layers it needs.
> >
> > It's a lot better than attempting to script things. For one thing,
> > git will
> > tell you the state of the submodules.
> >
> > If I rembemer correctly, Android builds use a tool to manage the
> > layer
> > repositories. I didn't much like it though. And "yet another tool"...
>
> It's called "repo" https://code.google.com/archive/p/git-repo/.
>
> In my experience git submodules work fine if you follow the core
> workflow of adding new submodules and updating them to newer versions.
> The workflows for deleting, renaming, changed upstream repostiory, etc.
> for submodules is IHMO pretty bad. Pretty much every time I've tried
> that it has resulted in a borked local repository that I either had to
> manually go into the .git directory and fix, or just start over with a
> fresh clone (perhaps I'm just bad at it or newer versions of git are
> better?). Not to say you shouldn't use them, just be aware of some of
> the catches so you can match the tool to your expected workflow.
>
> For my $0.02: We use git submodules to manage the multiple yocto trees
> we are pulling in and also keep "parallel" layers for each with the
> local changes we want to make in .bbappends, where possible (following
> the strategy of no modifying the original). We do (particularly for
> older versions of Yocto) make changes to the core since we have local
> mirrors, but we follow a strict policy of getting changes upstreamed
> first, and they trying to get upstream to backport to our version (if
> it is still supported).
>
> >
> >
> > Kind regards,
> >
> > Mike Looijmans
> > System Expert
> >
> > TOPIC Products
> > Materiaalweg 4, NL-5681 RJ Best
> > Postbus 440, NL-5680 AK Best
> > Telefoon: +31 (0) 499 33 69 79
> > E-mail: mike.looijmans at topicproducts.com
> > Website: www.topicproducts.com
> >
> > Please consider the environment before printing this e-mail
> >
> >
> >
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170819/4ab9037f/attachment.html>