I asked a question on the list around the kernel drivers. I know Hans is on PTO now, so I'd suggest we defer until he can discuss further.

I am hesitantly in support of this, but not ready to vote yet.

Much like @jwboyer I'm hesitant to vote on this yet, without a bit more discussion.

Hans hasn't returned from PTO and my question on the devel list remains unanswered. I'd propose deferring this until the relevant participants have time to comment.

Hans did comment on-list. He plans for Fedora to carry these drivers as a patch while they work their way upstream.

I'm going to vote this way: -1 unless the kernel team supports that approach.

Carrying patches is a nightmare we need to get away from except in exceptional (or sadly historical) cases. These should get into staging fairly rapidly and I think we should wait for that to happen.

This ticket was debated and voted upon in last Friday's FESCo meeting. FESCo would prefer that Fedora doesn't carry these patches for F27 release kernel, instead deferring until it is clear that there is a clear path they will be accepted upstream.

Hi,

I had no idea that FESco was going to discuss / vote on this. An invitation to join the discussion would have been ... polite. Instead I end up stumbling over this decision in a phoronix news item without ever having been given a chance to explain this further.

As explained in my mailinglist post the plan definitively is to get the kernel patches upstream. That is where I've been focussing all my efforts on:

https://github.com/jwrdegoede/vboxguest/commits/master

I'm planning on doing a first upstream submission of the patches coming Friday and as I already said to also mail the Fedora akernel-team then to ask them if they are ok with me maintaining these patches in the Fedora kernel pkg for a kernel release or 2.

Note that I've just finished removing a lot of cruft from the vboxguest driver, cutting it down from 100000+ lines to just 7000 lines. I've not undertaken all this effort to then not follow through and get this driver upstream. This driver going upstream is not a question of if but of when.

Regards,

Hans

Reading the meeting logs and the closing comment I see that the exact wording agreed up on is:

"FESCo would prefer that Fedora doesn't carry these patches for F27 release kernel, instead deferring until it is clear that there is a clear path they will be accepted upstream."

Which is not really helpful IMHO. I've no doubt that these patches will go upstream and the path is the standard upstream process. Actually I'm not even aiming for staging here. I believe the cleaned up version I'm going to submit is ready to be merged normally. So in my mind there is a clear path upstream...

One last comment:

Note I can understand that FESco does not like the prospect of carrying kernel patches for this for ever (like we are doing with the secureboot patches), but that is very unlikely to happen here.

Also the 2 missing drivers are very much standalone drivers not touching any other kernel code.

We have every confidence you will get the code upstream as well. When that's done, then this change can be re-evaluated. However, given the short duration for F27 it's certainly not critical to the release and there's really no harm in deferring it to F28.

As a side note, one of the kernel team members is on FESCo and already weighed in during the meeting. In the future, I'd suggest reaching out to the kernel team before submitting such proposals for review.