On 13.02.19 16:58, Paweł Chmiel wrote:
śr., 13 lut 2019 o 16:51 Tony Lindgren <tony@xxxxxxxxxxx> napisał(a):
* 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.
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.
I just can agree on that. I think a github repo/project/group might be a
good starting point.
Philipp
