[Ksummit-2012-discuss] [ATTEND] Your upstream maintainer just isn't that into you...
greg at kroah.com
Tue Jun 26 18:58:55 UTC 2012
On Tue, Jun 26, 2012 at 11:33:54AM +0300, Dan Carpenter wrote:
> On Tue, Jun 26, 2012 at 02:20:13PM +1000, NeilBrown wrote:
> > On Mon, 25 Jun 2012 20:44:47 -0700 "H. Peter Anvin" <hpa at zytor.com> wrote:
> > > On 06/25/2012 06:44 PM, Dan Williams wrote:
> > > > Can we do a better job of bounding the maximum latency for acceptance
> > > > or rejection of a patch? Are there barriers for maintainers asking
> > > > for or accepting help, even on a temporary basis?
> > >
> > > There shouldn't be. In fact, anyone can help a maintainer by reviewing
> > > patches and giving them a Reviewed-by: if good and feedback if bad.
> > >
> > Maybe the issues are more subtle.
> > Is asking for help a sign of weakness? Is that a problem?
> > Does asking for help impose on others? Does that make us reticent to do it?
> > Do we properly show appreciation when help is provided (BTW, thanks Dan for
> > recent review of some RAID5 patches while I was on leave - I really
> > appreciate it).
> > Do we have good role-models of maintainership? Linus, Andrew Morton, Greg KH
> > all do fantastic jobs, but appear a bit like one-man-bands. Are there good
> > examples of load-sharing that we can look to and emulate?
> Greg's not a one man show. Sarah Sharp and Alan Stern review USB
> patches. Several of the trees under staging have active
> maintainers. I help review staging patches. Alan Cox is stills
> reviews tty patches and Jiri Slaby does as well.
Yes, I am by far NOT a one-man show at all. I have some sub-maintainers
that send me git trees, which makes my life very easy, and Dan makes my
life very easy by doing lots of review of staging tree patches (for
which I am very grateful).
I have a lot of scripts that I use that I've written over the years.
Right now, the stable tree work is almost entirely automated, with the
exception of the patch review process, and that even is as automated as
you really want it to be.
I'm sure that most of the maintainers that do lots of work like Andrew
and David also have workflows and scripts that help them (my scripts are
based on Andrew's).
Would a basic, "here's how I work" type writeup or screencast help
people out with seeing how we do things to help other maintainers out?
I don't think it's worth a whole session at KS to go over this, but
perhaps it is if people feel it would be worth it. I know I've gotten
tips on how to use git from just about everyone I've seen use it over
the years, so perhaps a short 5 minute session from a few of us would be
More information about the Ksummit-2012-discuss