[Ksummit-2013-discuss] [ATTEND] stable trees and pushy maintainers; cgroups interface; hid; depth of maintainers tree

Jiri Kosina jkosina at suse.cz
Mon Jul 8 21:44:14 UTC 2013


Hi,

I'd like to attend Kernel Summit this year. Selection of the topics I'd 
consider worth discussing:

(1) I am a responsible maintainer of kernels for all SUSE enterprise 
    products. As such, I am dealing with -stable trees on a regular 
    basis. 

    I am aware of the fact that -stable team is deferring a big part of the 
    responsibility to the patch authors / maintainers (and thus they are 
    mostly the ones to blame), and also of the fact that properly 
    defining -stable acceptance rules is a very hard task.

    Still, my gut feeling is that some patches present in the -stable 
    release are obviously not a -stable material.

    As a basis fo further discussion I can provide a few examples of 
    patches hat went into -stable, although they (?apparently?) should have
    not, and they caused us headache.

(2) [I am sure this topic is going to be brought by gazillions of other 
    people, but still]: we have users who have their own scenarios how 
    they are currently using cgroups and might get terribly frightened 
    once they discover the on-going plans with cgroups integration into 
    systemd (or generally a namespace-isolated agent). I'd like to have 
    (a) better understanding of where everyone is standing in this mess 
    and (b) (sort of) final word on this from all the stakeholders

(3) My "usual" one:

    HID subsystem, which I am happy to maintain, has grown from "feeding 
    data mechanically into input layer" in several aspects -- it can be 
    seen as a "leader" in multitouch in Linux these days, and we are 
    extending its coverage of transport protocols as well 
    (not only USB/Bluetooth, but expanding to to I2C, IIO, and userspace 
    transport drivers mostly because of Bluetooth-LE).
    Thus, as we are gaining "cross-subsystem" coverage, discussion with 
    all affected subsystem maintainers is usually very productive and 
    welcome, with KS providing a good basis for it.. If "general KS  
    public" is interested, I can of course give a "state of the union"  
    short overview presentation (but I don't think so :) ).

(4) Is our tree too flat? This is rather a question to Linus than really a 
    proper discussion topic.

    It seems to me like there are many places where we are violating a 
    natural tree-like hierarchy our development model has, with many 
    people sending pull requests directly to Linus instead of going 
    through sub-maintainers.
    Is this really a problem? If so, how to deal with it?

-- 
Jiri Kosina
SUSE Labs


More information about the Ksummit-2013-discuss mailing list