[Openpvrsgx-devgroup] New version letux-pvrsrvkm-v5.6.0-rc1 available
tony at atomide.com
Tue Feb 18 16:27:05 CET 2020
* H. Nikolaus Schaller <hns at goldelico.com> [200218 14:31]:
> 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.
I just want to be able to do this type git standard stuff:
$ cd linux_openpvrsgx
$ git checkout my-dev-branch-i-last-worked-on-two-weeks-ago
$ git fetch linux_openpvrsgx
$ git diff linux_openpvrsgx/letux-pvrsrvkm-v5.6
looks fine, nice new fixes, i want to update to that
$ git merge linux_openpvrsgx/letux-pvrsrvkm-v5.6
hmm where was i? let's see
$ git diff linux_openpvrsgx/letux-pvrsrvkm-v5.6
And no, I do not want to rebase. Ideally the master branch would be
used with immutable commit id's, but in reality some kernel specific
topic branches are needed to work on let's v5.4-lts and current kernel.
And now you're going to got rant about me being able to use whatever
branch your cronjob created.. No I don't want to do that because
finding applied fixes to two new branches you already generated
is such a pain with the same patches appearing with different commit
> > 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?
This constant rebase, trying to figure out what other patches got
applied to n-number of more recent branches.
> 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.
No I don't want to work like that. It's too much of a pain to keep
up with these weekly branches.
> >>> 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?
Well I'm thinking to set up a tree for working on the new pvr-drv.c
parts with a goal of getting it into usable state for merging into
Linux kernel. Initially with 2d acceleration based on the gma500
code in the kernel.
> 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.
I really only have two issues with your current approach:
1. You are building a new topic branch every -rc once a week
while it should be only done once per kernel version for
2. You are using -rc specific branch names while mainline kernel
specific name would be sufficient
But please see below about the separate integration tree, maybe
that's the solution here :)
> 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.
OK so that's usable for your internal testing. How about set up
another git tree for integration testing? And just make itclear
that it's generated from the linux_openpvrsgx development tree
for integration testing?
That would leave out all the churn from linux_openpvrsgx development
tree and we can keep linux_openpvrsgx development tree usable for
> Another thing to consider is the GPL requirement to provide a
> source code for each binary which means to have an archive.
Yes.. But having tens or of different versions of git history sure
does not help with keeping track of that :)
> 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).
How about something like this:
1. Normal style git tree for linux_openpvrsgx with topic branch
for each major kernel version as needed
2. Separate weekly cronjob integration testing tree for your
purposes like your're doing now
3. I'll set up a minimal tree for pvr-drv.c only that can be
be merged as needed into #1 above
More information about the openpvrsgx-devgroup