Re: [PATCH] RFC: add MAINTAINERS file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Taylor Blau <me@xxxxxxxxxxxx> writes:

>>  - How binding is it for a contributor to be on this list as an area
>>    expert?  Will there be concrete "expected response time"?  It can
>>    be different for each area expert, of course.  I'd expect better
>>    from those who work on Git as a major part of their job and
>>    contributes some part of their work product back to the upstream,
>>    than from folks who do Git as a hobby.  Is each contributer
>>    expected to volunteer to be on this list, with self declared
>>    service level target?
>
> I share your concern here, too.

But I wasn't expressing any concern above ;-)

I'd consider it a progress if we can give contributors (and the
maintainer, too) more predictable review experience.  If we can even
optionally give some assurance on the response time, e.g., "I'll to
respond to and usher to completion any patches in this area if they
are promising within X days; I may not respond to all patches and
certainly not to ones that I do not find interesting" would already
be better than some patches that do not see any reviews for three
weeks without such an "optional" maintainer.

> Those kinds of things are hard to quantify exactly, and perhaps that is
> the point of a MAINTAINERS file.

Yeah, I am not interested in what exact form such a list of folks
who are willing to help guiding topics along comes from.  What I am
hoping to find out is if we can come up with a bit more structured
way to say "yes" or "no" to topics, rather than the current "nobody
may be interested in a topic, in which case it is anybody's guess
what will happen to it" (actually the default is "to drop", and I
often end up to be "somebody who gets sympathetic and reads the
topic to salvage, instead of the default action that is to drop").

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux