Branches: master vs. mbed-os-5.1

[betzw]

Can someone pls. help me in understanding what contains this repo's master branch compared to branch mbed-os-5.1?

[0xc0170]

The branching model will be explained soon.

Briefly, mbed-os-5.1 is a release branch, master is a develop branch. Everything lands on master, release branch gets updated biweekly (new patch releases - 5.1.x).

[betzw]

Are you using cherry-picking to the release branch in order to do this?
I am asking this just because of the currently big differences between master and mbed-os-5.1 (about 192 files differ).

[0xc0170]

We do use patch commands, for instance format-patch and am to do this job. We will describe this process in the branching document, plus the also the release process.

cc @sg-

[betzw]

Are you kidding?

[sg-]

Are you kidding?

About what?

[SeppoTakalo]

I think the question was about format-patch and am instead of cherry-pick and merge

Why would you do it manually if Git already gives you the tools to do it.
Also, why there is no merges happening from release branch back to master. How do we know that issues fixed in release branch are fixed in master?

Also, if master lags behind of release branch, what would be the baseline for testing our changes against? Do we send PRs against master or release?

[0xc0170]

Are you kidding?

Please provide more details, comments like this do not serve any purpose.

Why would you do it manually if Git already gives you the tools to do it.

Can you elaborate? We are automating this process now, won't be manual.

Also, why there is no merges happening from release branch back to master.

All lands on master, and cherry-picked to release. Therefore there won't be any merge other way around.

[betzw]

I am quite in line with @SeppoTakalo 's comments.
It's quite about using format-patch and am instead of other means in Git.
The only situation which I have seen where the use of email and am made sense was in Linux when you - as non recognized member of the Linux kernel developer community - wanted to provide a patch to the kernel and start a RFC. This was an elegant way to avoid needing to give write access to your repositories (not sure if GitHub was already invented at that time) to unknown people. Not sure if you have a similar requirement here?

[sg-]

Only new targets and bug fixes are taken to the release branch. This is done by us as part of creating a release so the method shouldn't much matter.