[Ksummit-2013-discuss] [ATTEND] tip tree workflow

[James Bottomley]

On Tue, 2013-07-23 at 10:14 +0800, Li Zefan wrote:
> On 2013/7/23 6:19, Olof Johansson wrote:
> > arm-soc tends to have quite a few cross-dependencies with other
> > subsystems and we've had our share of opportunities to adjust the way
> > we handle things based on that and other things. My contribution would
> > be along those lines; compared to -tip, what's worked well for us and
> > not, workflow, tooling, etc.
> > 
> 
> Why we don't have Documentation to describe/demonstrate a general workflow
> for maintainers? And no scripts and tools are poublicly available, while
> they can be very helpful for others.

This is mostly because there's no one true way to be a maintainer.  Some
maintainers (although this is getting rarer) don't even use git and even
those that do have different ideas about how to run their trees.

>  Those things can also help newbees
> and developers get to know how maintainers work, and so they can work
> better with maintainers.

The general rules are mostly documented in SubmittingPatches and they're
mostly independent of how maintainers actually work (so how to make a
patch series, how to be bisectable and how to submit via the mailing
list).  This is actually one of the strengths of the Linux patch
process: the mechanism for submitting is mostly independent of the back
end tools.

There's not much a newbie (or even a seasoned patch submitter) can do to
fit into a maintainer workflow because it's mostly about accumulation,
management and testing.  I certainly, for instance, wouldn't want to see
a git pull request from someone I'd never heard from before because
things like that short circuit the mailing list and usual review
processes.

Perhaps the only thing that could be better documented is how you know
your patch will make it on to Linus, and here it's mostly email you get
from the maintainer (or their patch scripts).

James