>>>> Harald and I were recently talking about kdbus and how it plays into >>>> Fedora. Right now, the kernel-playground COPR is carrying the kdbus >>>> patches, but that isn't widely used and isn't included in a broad test >>>> base. Obviously our distribution is heavily entwined with D-Bus and we >>>> were looking to see if it was possible to help kdbus testing and >>>> development by doing some kind of integration within Fedora itself. I >>>> promised Harald I would talk it over with the other Fedora kernel >>>> maintainers and after a brief discussion we came up with the following >>>> possible proposal. >>>> >>>> If Fedora were to carry kdbus in any form, the following things would >>>> be required: >>>> >>>> 1) There would be a single canonical location to track kdbus >>>> development. After talking with Harald, that should be the upstream >>>> tree that gregkh is using to submit patches. >>>> >>>> 2) Harald's team (systemd, etc) would commit to testing the system >>>> both with and without kdbus active. Obviously we do not want to >>>> enforce reliance on something as core critical as kdbus while it is >>>> still being actively developed upstream. That could cause a lot of >>>> deviation down the road and it isn't the aim here. >>>> >>>> 3) kdbus would only be carried in the rawhide branch until it is >>>> merged upstream. As a concrete example, if kdbus was not merged in >>>> the upstream kernel at the time rel-eng creates the F23 branches, then >>>> Fedora 23 will never get kdbus. It will be carried in rawhide and >>>> rawhide only until it's accepted upstream. The maintainers actually >>>> hope this does get merged but we want to make sure we are prepared to >>>> drop this without causing too much trouble if needed. >>>> >>>> 4) After discussing a bit with the rest of the Fedora kernel >>>> maintainers, we would carry an additional patch that would require >>>> 'kdbus-enabled' to be specified before the kernel would allow kdbus to >>>> be loaded (or similar mechanism). This would focus the main testing >>>> effort for all the default images to remain as they are today, while >>>> easily allowing the plumbing layer developers access to kdbus for >>>> their enablement testing. >>>> >>>> These conditions would hopefully help the Fedora kernel maintainers >>>> avoid some of the pitfalls of carrying a large chunk of out of tree >>>> code and if they're all met we feel fairly comfortable with doing >>>> this. We wanted to send this out for a bit wider discussion and >>>> review before proceeding with it, and I agreed to start this thread so >>>> here we are. >>>> >>>> Harald, does the above look like what you were envisioning when we >>>> talked earlier? >>>> >>>> josh >>>> >>> >>> Looks very good except for point 4, where we wanted to enable kdbus by >>> default >>> and have a "kdbus=0" command line option. >> >> Right, but that is actually counter-intuitive from the distro >> perspective. If we aren't going to ship kdbus in a release before >> it's merged upstream, then you want all the regular default testing >> that happens during that release's development to be done with what is >> expected to be the default. In most cases for now, that is likely to >> be non-kdbus. >> >> An argument could be made that since we're dropping kdbus at the >> Branched point if it isn't merged, there is time to test still but I'd >> like to hear other's thoughts on that. >> >> josh >> > > One possibility is to enable kdbus by default until alpha phase. > (-: Or make it alternate every two weeks or every reboot :-)
Well the enable until alpha is basically what Josh was suggesting with the in rawhide until branching bit because we branch just before we freeze for Alpha. On the alternate weeks/reboot proposal... rawhide contains a fast moving kernel already I'm really not sure a revolving door approach would be good for user or kernel team's sanity or kdbus as a proposal. The proposal here was to make it easier to be tested so getting it in the default installed kernel is clearly the biggest obstacle in this regard. I think maybe do the rest in two phases: 1) get it landed but leave it disabled by default 2) based on feedback of users then review whether enabling it by default is worthwhile. It's then easy to review and move forward. Ultimately I think we need the default to be what is going to be the default for the release it's being built for because otherwise the testing is useless for the distribution as a whole. Peter _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
