Hi Tony, > Am 13.02.2019 um 16:51 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > > * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [190213 15:22]: >> Do you have suggestions for a dedicated mailing list? > > How about something like open-pvrsgx-devel@xxxxxxxxxxxxxxx? > 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
