[Ksummit-2013-discuss] [ATTEND] hobbyists, stable, devicetree workflows

[Jason Cooper]

All,

I'd like to attend the Kernel Summit to participate in several
discussions.  In particular, I'd like to contribute the hobbyist (and
recruitment of more) point of view to:

1) stable trees
  I understand Greg's point about not putting too much work on
maintainers, but as a part-timer, I beg to differ.  When I encounter a
patch that claims to be a fix, the first thing I do is search for the
commit introducing the regression.  Once I have that, it's a single
command to determine which tags contain that commit.  imho, this is the
bare minimum a maintainer should be doing when encountering a fix.  From
there it's trivial to set it up for stable inclusion.

2) devicetree tree
  As a one of the ARM sub-arch (mvebu, kirkwood, etc) maintainers who
sees a lot of board files from first time contributors, I'd like to talk
about the devicetree bindings, how the migration is going to occur, and
how we can best facilitate patches getting reviewed/accepted.  This one
will probably be resolved in time for KS, but in case it isn't, I'm
mentioning my interest.

3) co-maintainership
  Since I started maintaining the kirkwood tree a little over a year
ago, I've been feeding into arm-soc, maintained by Arnd and Olof.
Recently, myself, Gregory Clement, and Andrew Lunn have set up a shared
tree (so we can take vacations :-) ).  I'd like to hear about how
everyone else does this and share what we do.

4) code of conduct
  If this is still on the schedule, I'd like to participate in this
discussion. In particular, it's potential ramifications on new
contributors.  As someone who has spent most of his life living in
contractually bound maintenance entities (Condo Associations in the US)
I am well versed in how they *always* degrade into a bully pulpit for
people who prefer to tell others what to do as opposed to doing real
work.

5) maintainer survivorship
  This was brought up when the KS ml first opened and I fear it got lost
in the weeds.  To me, encouraging first time contributors is the most
important factor in the long-term (beyond our lifespans) survivability
of Linux.  Eventually, Linus or other key people will want to retire (or
pass away), the larger the pool of active contributors/maintainers is,
the more there will be to choose a successor from.  It takes time for
anyone to come up to speed on the process, you simply can't do it
overnight.  Should there be a mentoring program?  Or is what we're doing
sufficient?

thx,

Jason.