> Am 13.02.2019 um 16:58 schrieb Paweł Chmiel <pawel.mikolaj.chmiel@xxxxxxxxx>: > > ś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. Yes, good! BR, Nikolaus
