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

[H. Nikolaus Schaller]

Hi Andreas,

> 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
>>>>> silly.  
>>>> 
>>>> 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
>> time).
>> 
>> 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
> situation.

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,
Nikolaus