[Openpvrsgx-devgroup] New version letux-pvrsrvkm-v5.6.0-rc1 available
H. Nikolaus Schaller
hns at goldelico.com
Mon Feb 17 09:00:29 CET 2020
> Am 16.02.2020 um 22:41 schrieb Tony Lindgren <tony at atomide.com>:
> * H. Nikolaus Schaller <hns at goldelico.com> [200211 13:28]:
>> A new version of our holistic PVR/SGX driver is available
>> Kernel: v5.6.0-rc1
>> Result: letux-pvrsrvkm-v5.6.0-rc1 (rebased on v5.6.0-rc1)
>> Result: letux-pvrsrvkm (linear history)
>> Github: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/branches
> For next branch you rebuild, can you please just leave out
> the "-rc" part from the branch name?
> If this branch was letux-pvrsrvkm-v5.6 instead of the
> current letux-pvrsrvkm-v5.6.0-rc1, you could just do:
> $ git merge v5.6-rc2
> When kernel gets updated, and also when v5.6 gets
> tagged, just merge it in and that's it :) Then make
> the next branch letux-pvrsrvkm-v5.7 instead of
> letux-pvrsrvkm-v5.7-rc1 to start with..
> I guess you could just fix this without rebasing for
> v5.6 with:
> $ git checkout -b letux-pvrsrvkm-v5.6
> And that way any branches based on the current
> letux-pvrsrvkm-v5.6.0-rc1 are still valid. But now
> if you go rebase patches again anybody with patches
> on top of it will need to scramble again.
If I understand you correctly this is exactly what the
"letux-pvrsrvkm (linear history)" branch is for. It is the
branch where the next release candidates are simply merged
in and potential changes/fixes placed on top.
So you should be able do the git merge v5.6-rc2 yourself
on this branch coming to the same result. I have not yet
tested if the new script is doing this right... We will
The idea is that this is a branch with "linear history".
Well, there are branch + re-merge so a better wording
may be "not-rebased history" or "reliable history".
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.
Yes, it is difficult to develop this outside of kernel.org
and keep track of upstream API changes without rebasing...
Would be much better and easier if that stuff were part of
Making clean patches for submission to LKML is also important.
If you just pile up commits the changes become buried under merges
and at some point it is not even possible to pull them out to the tip
of some linus/master without having to fix a lot of rebase conflicts.
This is we have switched to the "rebase every week model" some
years ago for the letux os kernel development. This way upstream
API changes and conflicts immediately become visible and the
feature branch is always potentially ready for submission.
The model is more similar to linux-next which is a big
merge of feature branches sitting on top of some linus/master
But if you develop something on top of linux-next you have
the same problems (if I correctly understand the problem).
More information about the openpvrsgx-devgroup