ś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. > > Regards, > > Tony >
