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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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).

James