[Openpvrsgx-devgroup] New version letux-pvrsrvkm-v5.6.0-rc1 available

H. Nikolaus Schaller hns at goldelico.com
Mon Feb 17 22:47:17 CET 2020

Hi Tony,

> Am 17.02.2020 um 22:08 schrieb Tony Lindgren <tony at atomide.com>:
> * H. Nikolaus Schaller <hns at goldelico.com> [200217 19:34]:
>> Hi Tony,
>>> Am 17.02.2020 um 16:00 schrieb Tony Lindgren <tony at atomide.com>:
>>> * H. Nikolaus Schaller <hns at goldelico.com> [200217 08:01]:
>>>> The scripts will also keep letux-pvrsrvkm-v5.6.0-rc1 untouched
>>>> and there will be a new letux-pvrsrvkm-v5.6.0-rc2 which
>>>> is rebased. So you can alternatively start on letux-pvrsrvkm-v5.6.0-rc1.
>>> Please don't rebase on every -rc. Just do it for every major release.
>>> That way we have a sane development tree following the Linux release
>>> cycle.
>> well, that contradicts the Letux development process where all feature
>> branches are rebased every rc (sometimes every second one). This is
>> sometimes essential to get bug fixes during rc2..rc7 into the tree. Or
>> not to keep hot-fixes twice (once from upstream and once local).
> If we have a branch for letux-pvrsrvkm-v5.6 originally based on
> v5.6-rc1, there's no issue whatsoever to merge v5.6-rc2 or any
> later -rc into it.
> When you merge in v5.6-rc2, the original commits stay there rather
> than change commit IDs compared to rebase. So you will get fixes
> just fine. Also merging in more recent versions of local patches is
> not a problem, you just merge in some dev branch with more recent
> local changes.

Yes, I know how and that git works :)

It is just that you don't have your patches at the tip of the branch
and a well known base name.

>>> Shorter branch names, less work for you, folks with their own forks
>>> will be happy as there's only need to rebase every major release :)
>> Unfortunately it is much more work because I don't see how I can automate
>> that...
> It seems like you already have the scripts, just run them less
> often :) Only run them when new -rc1 gets tagged :)
> And when during the -rc cycle, you just do this:
> $ cd linux
> $ git checkout letux-pvrsrvkm-v5.6	# Assuming still on -rc1
> $ git merge v5.6-rc2
> And you're done.

Yes, you can do that. Unless the git merge v5.6-rc2 reveals a merge
conflict (yes, this happens). Then you are lost with automation.
Because the conflict must be solved in the feature branch (because
we always want a clean feature branch for each individual feature)
and after merging all feature branches you have a good -rc2 that
compiles and works again.

>> And maybe you can take "-rc1" suffix just as a note that it is the basis
>> of a new major release and assume it has been removed :)
> The issue I have it's that the commit IDs constantly keep
> changing when you rebase.

No, they don't. Not in the letux-pvrsrvkm branches. Only in the
underlaying letux/pvrsrvkm feature branches.

letux-pvrsrvkm-v5.6.0-rc1 is 45c2644abce96e0840e839c030be7cf376a93bd4

and will stay until the git repo or this branch is deleted.

letux-pvrsrvkm-v5.6.0-rc2 will be different of course but also
stay stable.

This is the new scheme I have installed in the past weeks for the
pvrsgx builds and until end of last year this was indeed different.

The same is for our Letux kernel releases. There is a series of
branches for each minor release by Linus.

We also need this to be able to store binaries and have the source
code available as GPL requires. For example:


has binary downloads and


gives you a link to the full source tree. The commit hash must of
course be stable or that won't work.

> I have no problem with a new branch every new kernel version.
> That can be considered a separate development branch, and
> the old branches can potentially be active too still.
>> In summary it was not difficult to clone your letux-pvrsrvkm-v5.6.0-rc1-pvr-drv
>> and cherry-pick the series from letux-pvrsrvkm-v5.6.0-rc1..HEAD to
>> reintegrate into letux-pvrsrvkm-v5.6.0-rc2. Which should now have
>> almost all patches except the jz4780 patch.
> Please no. Do not rebase if you want others to use your git tree.

I do only rebase feature branches, not the results where others
can base their work on.

> Linus has explained this with very good arguments many times
> over the years, see for example [0] below.

I know this. It works only for a single person (Linus) publishing
an official linear series of work which includes patches from others.

We are working ahead of Linus - to be able to provide patches for Linus.
And to provide functions to users before review and upstream submission.

Yes, he says this can be done in private trees to have private history.

But that does not work if you have your own team working on different
parts and goals.

For example we have code that was rejected by upstream maintainers
or will never go upstream. But all this has to end up in a letux kernel
release. So we do a merge of feature branches (like linus-next). And
to avoid merge conflicts it is much easier if all feature branches
have the same base (i.e. are rebased regularily).

Believe me, I would have preferred to do it without any rebase but
it is simply not possible - unless we give up some goals or make
cooperation more difficult in other areas.

> Basically it's not just your change log history any longer when
> you push out a git branch and other people start particpiating,
> it's also other people's change log history then too.

> Regards,
> Tony

So please wait for the build process to finish letux-pvrsrvkm-v5.6.0-rc2
and see that stays letux-pvrsrvkm-v5.6.0-rc1 is unchanged. If not,
there is a bug in my script, not an intention.


More information about the openpvrsgx-devgroup mailing list