[Ksummit-2012-discuss] [ATTEND] depth of our git tree structure; HID subsystem; kernel bugzilla; stable review

[Guenter Roeck]

On Fri, Jun 15, 2012 at 11:32:23PM +0200, Jiri Kosina wrote:
> Hi everybody,
> 
> I'd like to attend Kernel Summit this year. Selection of the topics I'd 
> consider worth discussing:
> 
> (1) 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 
>     affected subsystem maintainers would be welcome. If "general KS 
>     public" is interested, I can of course give a "state of the union" 
>     short overview presentation.
> 
> (2) This might be more question to Linus rather than discussion topic, but 
>     still ... Time to time I have a gut feeling that our development 
>     "tree structure" is not as deep as it could/should be, mostly because 
>     many people are sending pull requests directly to Linus instead of 
>     going through appropriate "upstream" trees.
>     I'd like to know whether it's just me having this feeling, or there 
>     are other maintainers sharing this. If the latter is the case,  
>     discussion might be useful.
> 
> (3) Kernel bugzilla; do we really want it for general public bug reports? 
>     For trees I am maintaining, I very much prefer all bug reports and 
>     patch reviews/discussions to happen via e-mail; consequently, I am 
>     not very careful when it comes to reports received through 
>     bugzilla.kernel.org, and tend to drop bugzilla-reported issues on the 
>     floor silently. I understand that users/bug reporters might be 
>     confused in which cases to prefer bugzilla over mailinglist (and vice 
>     versa), so it'd be nice to actually try to improve the situation 
>     here.
> 
> (4) I am a responsible maintainer of kernels for all SUSE enterprise 
>     products. As such, I am dealing with -stable trees on a regular 
>     basis. It's sometimes difficult to decide about -stable tree merge 
>     into our enterprise tree (depending on the development stage of the 
>     enterprise kernel), due to the amount of changes it flows into 
>     -stable. I'd like to understand whether all the patches are really 
>     always necessary, and how can we help with review/filtering.
> 
Doing the same for my employer, I have not had much (if any) trouble with that.
There may be some glitches (I usually wait for a week or two before pulling in a
new kernel), but overall I think the stable maintainers are doing an excellent job.

My problems in respect to -stable are:

- stable tree submission process, which doesn't apply to all subsystems.
  Would be great to have a single well defined process for all -stable
  submissions. That doesn't mean that all patches sent to -stable have to be
  handled by the same person, but the "patches for the XXX subsystem are not
  handled here" feedback is a bit odd for newcomers.

- stable release selection process. Would be great to have some predictable
  process, ie to know ahead of time if a release is going to be a stable release.
  That would make long term release planning much easier.

Guenter

> (5) If James is invited so that he can (in the order of several 
>     magnitudes) increase the number of people in the group who 
>     actually know how to dress for formal ocasions properly, I'd like to 
>     pay my debt to him (I have promised to let him taste a really good 
>     plum brandy, but the brain cell that was responsible for not 
>     forgetting this died prematurely last year).
> 
> Thanks,
> 
> -- 
> Jiri Kosina
> SUSE Labs
> _______________________________________________
> Ksummit-2012-discuss mailing list
> Ksummit-2012-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss
>