Hi Tony,
Am 13.02.2019 um 16:51 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190213 15:22]:
Do you have suggestions for a dedicated mailing list?
How about something like open-pvrsgx-devel@vger.kernel.org? I think all you have to do is email the vger.kernel.org postmaster and explain what this list is about.
Yes, looks good!
Or a common git repo to use?
How about initially set up somethign at gitlab/github as suggested by Paweł?
And then also get a kernel.org account and start setting up a proper open-pvrsgx-devel git branch at git.kernel.org eventually for the mainline kernel module(s)?
Ok, so have a sub-git there. Feels right.
As said, I'd prefer kernel.org/staging and linux-omap (because we seem to be the largest group) because it would make things simpler.
Sure, I'm just saying we should wait a bit until we have code ready for staging to avoid churning the Linux kernel pointlessly initially.
Yes that makes sense as well.
And there is another aspect which came to my mind just now.
Having a separate ML + GIT needs activities to draw attention of other developers while sitting on kernel.org would automatically make use of the existing Linux announcement channels. Some 5.x-rc1 would simply include it. ELIXIR will cross-reference it. Patchwork will archive discussions. LKML will present patches to all potential developers. So we would make use of the existing communication machinery besides a ML.
Yeah there's nothing stopping you from getting a kernel.org account and setting up something like open-pvrsgx-devel git tree there to start with.
Ok, I could easily push the current letux/omap-pvr and letux/latest-pvr branches there since they are already based on linus/master and therefore not tied to the Letux OS.
As we've discussed, these are already GPL components for the kernel although unusable in their current form.
This raises the question who wants to take the maintainer's head (at least initially)...
I am not sure if I want to do it because I already spend too much voluntary time on Linux :) So if someone else would like to take this role, I'd step back.
Having it separated needs also some HOWTO for integration and getting it compiled.
So I see a lot of benefits.
But this would need to get Greg into the boat or at least accept what we are doing and providing resources. You likely know him better than me. How should we contact him?
I think we should just wait on the staging part a bit until we have something usable. There will most likely be a lot of churn initially.
Ah, ok.
Sounds like a good strategy. Have ML and separate GIT hosted at kernel.org for visibilty.
And then if work matures and becomes useable, we clean up the working branches and contact Greg and whoever else for official inclusion in linux-next. Then, development can continue in official staging.
BR and thanks, Nikolaus