śr., 13 lut 2019 o 16:51 Tony Lindgren tony@atomide.com napisał(a):
- 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.
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)?
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.
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. As we've discussed, these are already GPL components for the kernel although unusable in their current form.
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.
I also agree to this. In my opinion, we should at first try to get something working (it doesn't matter where it will be, we can easly move code it later - just make sure all have access). Also someone mentioned about adding some prefix to all commits - we can do this later when we'll be preparing patches for submision (for example formatting them according to kernel rules, squashing so we could send them for example with few commits - don't need to send whole history of changes from repo). For now we would just need to signoff patches.
Regards,
Tony