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

H. Nikolaus Schaller hns at goldelico.com
Tue Feb 18 15:30:10 CET 2020


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.

> 
>>> Let's make this git tree behave like a normal Linux development
>>> git tree so we can use git in a standard way.
>> 
>> You can use it in the way you have explained that you want to use it.
>> 
>> Just take letux-pvrsrvkm-v5.6.0-rc1 and letux-pvrsrvkm-v5.7.0-rc1
>> as your basis and ignore the others.
>> 
>> I don't see where the problem is with this on your side.
> 
> Sorry to hear that. I'll just set up a new normal style git tree
> for the driver development then.

How would that look like?

If that is easy enough, I once again do not understand your problem.
And you do not seem to accept that I have a problem with other
approaches than we have.

It is for reasons and based on bad experiences with other concepts.
We are running a factory of kernels that are ahead of Linus/master
but must work with always changing feature branches, because the review
process requires us to permanently rewrite the history to derive
and submit clean patches. And this sometimes takes months or even
years until it is settled. So we can't wait to integrate.

Another thing to consider is the GPL requirement to provide a
source code for each binary which means to have an archive.

So I really want to understand and learn but I do not see how
it keeps my problems solved (which we have for a while).

Best regards,
Nikolaus



More information about the openpvrsgx-devgroup mailing list