Discussion: How to handle HALs, SDKs and libraries

[oss at c-mauderer.de]

Hello Karel,

Am 15.07.23 um 15:03 schrieb Karel Gardas:
> On 7/15/23 14:33, oss at c-mauderer.de wrote:
>>>> I like submodules because they are well-supported by the usual tools. 
>>>
>>> Honestly. I like submodules idea, but hate its implementation. Some 
>>> reasons:
>>>
>>> - submodules were added as a light weight feature and during the 
>>> development of git/submodule feature they accumulated some more.
>>>
>>> - submodules started as way to get commit id of the external project 
>>> to the tree. But only master branch was supported. (not suitable for 
>>> RTEMS)
>>>
>>> - later submodules added capability to use tag (still not suitable 
>>> for RTEMS)
>>>
>>> - later submodules added capability to use different branch from the 
>>> project, but only a head of it. (finally what RTEMS need).
>>
>> I don't like using branches instead of fixed commit IDs. Otherwise, 
>> it's not possible to reliable re-build a fixed version.
> 
> And this is most important detail, so let's discuss this alone.

OK.

> 
> I have a hal library, let's consider this to be 
> https://github.com/karelfv/stm32h7xx_hal_driver -- just one project for 
> now.
> 
> This is a fork of ST Micro project of the same name which is a slow 
> development project. Few accumulated commits over one year let say.
> 
> This project needs few RTEMS related patches and there is a chance they 
> also need to kind of adapt to the new development. So let's branch as:
> 
> - master branch -- this is fork of ST Micro
> - rtems-6-branch -- this is a branch from master at one point of time 
> accumulating RTEMS related changes.
> 
> Now, let's assume this was done 6 months ago and now you would like to 
> update from ST Micro upstream. How would you do that? I see:
> 
> - git fetch upstream inside the master
> - git push master
> 
> that's update of master in fork and now:
> 
> - pull/merge master
> or
> - rebase master
> 
> in the rtems-6-branch? I'm afraid rebase is dangerous in shared setup so 
> probably pull/merge?

We should avoid rebasing and overwriting the old branch because we have 
to preserve a version that can be used with older RTEMS versions. So for 
rebasing, we would have to use multiple branches. Instead of 
rtems-6-branch, it could be a rtems-<date-of-base-revision> or something 
similar.

I think that depends heavily on how the upstream project works. If the 
upstream project uses a typical git workflow and is quite active, 
merging is most likely the better solution because we don't get big 
amounts of branches with that.

On the other hand I know that some semiconductor manufacturers tend to 
just dump code into a repo and they don't care whether files move around 
or change heavily. They happily mix changes with reformatting the 
complete code. In that case you have no chance of a useful merge-commit. 
I think in these cases it's most likely better to create a new branch on 
every update and rebase the patches.

> 
> Anyway, still this is a branch based workflow. How would you do that 
> workflow with just fixed commit IDs?
> 
> I'm asking since so far commit IDs on submodules were always obtain from 
> master branch which is what we basically fork and does not give us 
> ability to patch with RTEMS changes...
> 
> So I'm curious how would you do that?

I think I have put that in the wrong words. I assumed you mean that you 
want to use some feature that always uses the latest commit of a branch 
(also I don't know whether git even has that feature).

What I wanted to say is that if I check out a RTEMS version from two 
months back, it should check out the revisions of the submodules that 
have been used in RTEMS two months back too. It must not use the latest 
HEAD of the branch from today. It's just part of having a version of the 
code that can be reproduced later.

Of course the revision from two months back has to be available in the 
repo. It doesn't really matter whether it's on master because the code 
just worked or whether it's a RTEMS specific branch because adaptions 
have been necessary.

Best regards

Christian

> 
> Thanks!
> Karel
> 
>