Mainlining improvement ideas

From eLinux.org
Revision as of 12:03, 5 October 2015 by Tim Bird (talk | contribs)
Jump to: navigation, search

This page has a list of ideas for improving mainlining activities for large out-of-tree code bases (often found in mobile products).

These were gathered from meetings and online forums. An attempt has been made to recognize the source of the idea. Please accept my apologies if you thought of something here but are not credited.

from ELC SIG meeting on SoC mainlining

from LWN.net article about the LCJ "obstacles" talk

Here are ideas that were posted on LWN.net in response to their coverage of Tim Bird's "Overcoming Obstacles to Mainlining" talk at LinuxCon Japan. See https://lwn.net/Articles/647524/

Summary of ideas:

  • 1. binary blobs should be discouraged, as they freeze downstream to particular kernel versions
  • 2. NDAs are another obstacle to contributing
  • 3. use staging for non-mainlinable code
  • 4. mail patches to LKML for future reference, even if not for mainlining
  • 5. make software costs visible
  • 6. get hard data on costs for out-of-tree code
  • 7. make hardware available to the community
    • make it so that phone owners can work on mainlining
  • 8. make a dumping ground for non-mainlined source
    • possibly use automation to create it
  • 9. vendors should release kernel source ASAP, to reduce customer wait for source
  • 10. create a wiki page with links to source trees

from ksummit-discuss thread

 How hard would it be to get "patch" or "git apply" to apply
 white-space-damaged patches?  Wiggle does a good job of a certain
 class.  I came this --><--- close to getting wiggle to strip trailing
 '\r', but I never received that third patch to push me over the edge.

 How hard would it be to create a pre-commit hook that strips trailing
 spaces, NormalizesCamelCase, and imposes Reverse Christmas Notation (or
 whatever it is).  It could even add "FOO:" to the start of the
 patch summary for any patch which modifies the "FOO" subsystem.

 How hard would it be to have an SMTP server on submit.kernel.org which
 only accepts properly formatted patches addressed to
 "linux@kernel.org", performs basic compile tests, runs get_maintainer
 and sends it off to the appropriate places.  Then Eager Developer could
 just "./scripts/config-email", answer two questions, and "git
 submit" (or whatever) would submit their pride and joy to the correct
 place.  ./scripts/config-email would probably install the pre-commit
 hooks so that bad white space would never even get to git.
  • (Tim Bird) modify patch or wiggle to accept include lines and variable declarations without context

ideas from LinuxCon NA 2015 BOF

[put stuff here]

discussion from ELCE 2015 BOF

Ideas discussed:

=== Company incentives === Easier path to mainline === Tools for mainlining === Technical projects