[Openpvrsgx-devgroup] New version letux-pvrsrvkm-v5.6.0-rc1 available
H. Nikolaus Schaller
hns at goldelico.com
Tue Feb 18 20:55:54 CET 2020
> Am 18.02.2020 um 20:40 schrieb Andreas Kemnade <andreas at kemnade.info>:
> On Tue, 18 Feb 2020 15:30:10 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>> Hi Tony,
>>> Am 18.02.2020 um 15:06 schrieb Tony Lindgren <tony at atomide.com>:
>>> * H. Nikolaus Schaller <hns at goldelico.com> [200218 05:42]:
>>>> Hi Tony,
>>>>> Am 17.02.2020 um 23:19 schrieb Tony Lindgren <tony at atomide.com>:
>>>>> * H. Nikolaus Schaller <hns at goldelico.com> [200217 21:48]:
>>>>>> letux-pvrsrvkm-v5.6.0-rc2 will be different of course but also
>>>>>> stay stable.
>>>>> Argh no.. Please just stop doing this pointless weekly respinning
>>>>> of branches stuff. There's absolutely no point setting up a new
>>>>> git branch for every Linux -rc kernel every week. That's just
>>>> No. I have explained the reasons.
>>> Sorry this rebuilding of git trees does not work for me for Linux
>>> kernel driver development.
>> Can you please explain, since it seems I still have not yet understood
>> your problem and how a "standard way" would be better.
>>> It's too much of a pain for me already and I only have two sets of
>>> patches so far (for ddk 1.9 and ddk 1.17).
>> So what is the pain?
>> In my understanding it suffices to git checkout letux-pvrsrvkm-v5.6.0-rc1
>> and add new commits to it. And let me know if you have new ones. Then I
>> can cherry-pick them into the feature branches (like I have done this
>> If you want to take patches from letux-pvrsrvkm-v5.6.0-rc2 just cherry-pick
>> them or decide to rebase.
> hmm, I can understand the point here. Cherry-picking and comparing what is new
> is more cumbersome than just merging. There are some things different here
> compared to what happens in letux trees. So if something was good in letux it
> does not necessarily mean that it is good here.
> - here more people work more intensively on a single, quite big topic.
> - on letux we had often one person per topic,
> - on letux we have many branches which are in upstream process and there
> things are rebased anyways to work in maintainers/reviewers comments and
> have a topic-v(x+1) branch aftervards
> or stalled because things seem not to or too hard to be upstreamable
> - many things happend and were upstreamed before this rebasing scripts
> were in place
> - many things in letux branches now can simply be developed independently
> of other letux stuff
> So I think it is a good time to recheck the workflow for this different
Indeed - we have quite contradicting requirements/expectations for the
workflow. And I understand that we need to have both. Somehow combined :)
> And please do not stop working together because you have different
> opinions about git.
> I guess it is a good chance to learn a lot. Hmm, what about
> rebasing the pvrsrvkm stuff only at -rc1 and merging that thing also
> into letux-rcX (X >1) kernels. I guess we will have everything then and in a
> simple way.
Hm. Yes, that could potentially help here.
But I am not sure if I can automate it easily... Basically the merge
is a script with a control file that tells which branch names should be
rebased/merged into a single result (or multiple). Similar to the
linux-next control file.
But it does not know anything about rc or similar things. It just does one
thing: merging feature branches on top of some base (whose name is
"letux-base" but also stable in the control file). So the rebase touches
either file or all.
Anyways, this another puzzle piece which may help to find a solution.
BR and thanks,
More information about the openpvrsgx-devgroup