On Thu, Jan 14, 2016 at 5:29 PM, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > On Thu, Jan 14, 2016 at 5:07 PM, Zach Villers <zachvatwork@xxxxxxxxx> wrote: >> Well - If there was to be a plan, it would have to start with RH legal >> making that determination would it not? >> >> Could FESCO or the other council (sorry it escapes me ATM) take this up as a >> meeting item? Is it worth presenting for a legal determination? You can contact legal@xxxxxxxxxxxxxxxxxxxxxxx with legal questions independently of any FESCo/Council items. > There are two councils that matter: the Fedora Council[0] and the > Fedora Engineering Steering Committee[1]. Both of these will likely > have a say in this matter. > >> In my mind, if it was approved by legal we would have to; >> >> A - determine with we were going to start building a kernel with nodebug >> turned off AND if it needs to be maintained as a separate kernel package to >> make sure that the kernel version tracked is supported by ZFS. > > This should not be necessary, as our kernel is very close to mainline, > making it quite easy for kmod authors to target. > >> B - Be prepared to support a filesystem that needs modules build by DKMS > > This shouldn't be too terrible, as most of the userspace would treat > it like any other filesystem. Except for that whole other thread you started where I laid out why we said we aren't going to do kmods as a deliverable from the Fedora project. If one wants to start this in a separate repo, that's up to them. >> C - Find maintainers ( I would volunteer - I'd have to learn packaging) > > I'd certainly be willing to assist if it were allowed. I will be honest and say I do not foresee this being allowed in an official capacity. People are better off using the existing ZFS repo or contacting rpmfusion about it. To be clear, maintainers would need to be willing to deal with any and all kernel issues reported with ZFS loaded. We cannot staff the existing "next-generation" filesystem that is already upstream, let alone another that never will be. Also, willing maintainers should be item A :). >> D - Plan what release/testing, etc.... > > Again, definitely willing to help out here. > >> E - Decide if it when/if it would be supported in the installer and make >> those changes as well > > I would hope that Anaconda would grow support for it if we did have it. > >> F - do other stuff... >> > > What else do you think would need to happen? > >> Should this be presented on another list? >> > > I think all the relevant stakeholders are present on this list. *If* > this goes anywhere, Being transparent, I don't see this making it past legal. On the very off chance it did, I don't see it making it past some of the other policy and technical hurdles we have. > then we would make a proposal to the Fedora > Packaging Committee[2] for a policy change. A change for what? Allowing kmods in Fedora? DKMS itself is already provided, but we do not provide binary kmods themselves. I've already explained why in the other thread. Or do you somehow mean shipping module source that is then built on user's systems? That seems... fragile at best. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
