Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning

[Josh Poimboeuf <jpoimboe@redhat.com>]

On Fri, Oct 06, 2017 at 08:27:45AM -0700, James Bottomley wrote:
> On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote:
> > Appendix: Other topics that were brought up
> > -------------------------------------------
> > 
> > Documentation
> > Bug reporting feedback loop
> > Driver and/or module versions
> > Developing across multiple areas of the kernel
> > ABI feature gates
> > tracepoints without user space interfaces (EBPF)
> 
> I've got a couple of extra possibilities
> 
> 1) git tree script alignment.  Most of us send out some type of your
> patch was added and your patch was dropped email notifications.  We
> usually automate it through a private tree git commit or update script.
>  Should we standardise these (because if we do, we could have
> kernel.org do it for us instead of running our own infrastructure).
> 
> 2) Trivial patches (again). OpenStack has recently started to become
> annoyed by these 
> 
> http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122472
> 
> I thought about our process around the trivial tree, but it hasn't been
> updated in the last few releases, so effectively we no longer use it.
>  So is what we're currently doing (variable standards by tree) OK, or
> should we have a more concerted trivial policy?
> 
> 3) Tasteful Rebasing. We've come around (finally) to the conclusion
> that rebasing isn't always bad.  My own opinion is that rebasing to fix
> issues in patches (particularly those marked for stable) so they can
> backport cleanly and atomically.  There's also less of a consensus that
> rebasing to clean up history is a reasonably good thing (provided it's
> not done just before requesting a pull).  However, we have a divergence
> of opinions not just on whether we should rebase, but what constitutes
> a tasteful rebase.  Just telling people, particularly would be new
> maintainers, that it's a judgement call always is unhelpful, we could
> do with putting together some more detailed guidance (assuming we can
> agree on it).

Maintainers seem to have a lot of tribal knowledge, which is
self-taught, or passed on by word of mouth, or learned the hard way when
they make a mistake: branch management, merge conflicts, rebasing, pull
requests, cross-tree changes, release candidate timing, co-maintainer
processes, etc.

I think it would be a good idea to have a Maintainer's Guide which tries
to document a lot of this knowledge.  It would help new maintainers
learn the ropes, and would also help drive consensus for maintainer's
best practices.  It could document the typical processes of a
maintainer, and policy guidelines like some of the above topics.

-- 
Josh