Hi Gyorgy,

Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. There are three branches in TF-A: - "integration" branch, should be used for new features. - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. @Soby Mathew Could you help to share more information about it? Thanks very much.

Hi David W,

Thanks for your comments. For your first comment, I will say yes. Sorry to give the CI problem as a reason. For your second comment, I think we can use " git merge <commit-id>" to merge up to a special commit of dev to the master branch. In this, we do not need to freeze the patch merging. Maybe other methods to do it. Sorry, I am not a git expert, please correct me if it is wrong. I agree with you that we need to think clearly about it.

Thanks, Edison

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, December 11, 2019 3:58 PM To: David Wang (Arm Technology China) David.Wang@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Create another branch for feature development

Hi,

Please sync up with the TF-A team on branching strategy. It would be preferred to keep the two projects aligned if possible.

/George

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 11 December 2019 07:59 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Create another branch for feature development

Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that.

A few comments:

...

• Reduce the risk to broke the master branch directly especial when the CI cannot work rightly.

This reason of creating dev branch seems like a workaround as CI is not stable.

...

• We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release.

If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted.

For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches.

Just share my thoughts.

Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142)

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) Kevin.Peng@arm.com; 'tf-m@lists.trustedfirmware.org' tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Create another branch for feature development

Hi Kevin,

Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly.

And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix.

Thanks, Edison

-----Original Message----- From: Kevin Peng (Arm Technology China) Kevin.Peng@arm.com Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) Edison.Ai@arm.com; 'tf-m@lists.trustedfirmware.org' tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Create another branch for feature development

Hi Edison,

In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu?

Best Regards, Kevin

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [TF-M] Create another branch for feature development

Hi all,

I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are:

* Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release.

More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing.

Welcome to comment on this.

Thanks, Edison