Re: [Qemu-devel] [RFC 00/14] MAINTAINERS cleanups - please read

[Anthony Liguori]

On 04/16/2012 12:17 PM, Peter Maydell wrote:
> On 16 April 2012 17:03, Andreas Färber<address@hidden>  wrote:
> > Am 16.04.2012 18:00, schrieb Anthony Liguori:
> > > On 04/16/2012 09:31 AM, Andreas Färber wrote:
> > > > Hello,
> > > >
> > > > Sparked by conversations with Anthony and the discussion on a recent
> > > > KVM call,
> > > > I've started overhauling our MAINTAINERS file.
> > > >
> > > > Patches 1-5 fix syntax issues.
> > > >
> > > > Patch 6 documents our orphaned stable trees, as requested by Anthony.
> > > >
> > > > Patch 7 drops the orphaned and by now completely busted darwin-user
> > > > emulation.
> > > >
> > > > Apparently we have unwritten eligibility criteria for new maintainers
> > > > in terms
> > > > of qemu-devel participation and patch handling quality, but no formal
> > > > mechanism
> > > > to handle replacing lost maintainers.
> > > >
> > > > The current practice has become for Anthony to expect people listed in a
> > > > MAINTAINERS section with S: Maintained to handle patches in that area
> > > > themselves
> > > > and to supply a [PULL] request to get those changes into qemu.git.
> > > > This has the downside that patches falling into an area, where a
> > > > maintainer
> > > > is listed but not responding, simply bitrot on the list.
> > >
> > > I think we ought to aggressively downgrade subsystems if this is really
> > > a problem.  Unfortunately, it's hard to judge whether this is a problem
> > > until someone complains about a specific subsystem.
> > >
> > > > Patches 8-11 therefore propose to upgrade some actively maintained
> > > > sections
> > > > to Maintained to formalize the Maintained vs. Odd Fixes semantics:
> > >
> > > > Maintained means PULLs from maintainer expected.
> > >
> > > Yes.  More specifically, if something is Maintained, I would expect the
> > > patch to always come in through that specific tree.
> > >
> > > > Odd Fixes means Reviewed-by/Acked-by or committer's gut feeling is
> > > > sufficient.
> > >
> > > Yes.  Odd Fixes and below means the patch is "fair game" but that the
> > > listed M: probably ought to at least be consulted.
> >
> > The current status descriptions seem to be a copy from Linux. Could you
> > address Kevin's comment by proposing a change to the descriptions in our
> > copy?
>
> Here's my stab at it:
>
>             Supported:   Someone is actually paid to look after this. This
>                          is the same as Maintained (see below) but you might
>                          have a greater chance of faster response times.

Let's drop Supported as a status.

>             Maintained:  Someone actually looks after it. The maintainer
>                          will have a git subtree for this area and patches
>                          are expected to go through it. Bug reports will
>                          generally be investigated.

* For something to be marked Maintained, there must be a person on M: and there 
must be a git tree for the subsystem.

>             Odd Fixes:   It has a maintainer but they don't have time to do
>                          much other than throw the odd patch in. Patches are
>                          applied directly to master; there is no subtree,
>                          and no requirement for an Ack from the maintainer
>                          for a patch to be applied. Bug reports without
>                          reasonable quality patches attached are likely to
>                          go unfixed.
>             Orphan:      No current maintainer. Send patches to qemu-devel;
>                          persistence may be required to get something reviewed
>                          and committed, especially if it's a large change.
>             Obsolete:    Old code. Something tagged obsolete generally means
>                          it has been replaced by a better system and you
>                          should be using that.

I like these descriptions a lot more.

Regards,

Anthony Liguori

> (I dropped the parenthetical about becoming a maintainer of an orphan
> area; if we want to keep that I think an expanded section about how
> to demonstrate that you might be capable of the job, how/when to add
> sections for new code/drivers/boards, etc would be more useful.)
>
> -- PMM