[fab] Re: "community maintainers working on core" dilemma

[Greg DeKoenigsberg]

On Wed, 9 Aug 2006, Christopher Blizzard wrote:

> > My preferred variant:
> > 
> > 1. community developer commits his changes to a version control system
> > somewhere
> > 2. he sends some kind of pull request to the red hat maintainer
> > 3. red hat maintainer looks at the changes
> > 3a) he doesn't like them -- he mails the community maintainer some
> > reasons why he doesn't like them
> > 3b) he likes them -- he pulls them and queues build
> 
> I think that we could actually remove some steps here.  We need to make 
> it so incredibly easy to link developers, fixers, testers and 
> maintainers that the bar to fixing something is always about waiting on 
> people and never about fighting with technology or wading through bugzilla.

Is there an actual suggestion in there?  :)

OK, take two.

We have an email list for all community patches to Fedora Core.  It's
called something snappy like "fedora-core-patches-list".  An email to it
looks like this:

===

Subject: Patch: kdelibs-3.1.8-4.4

Hey, Red Hat maintainer, here's a patch to kdelibs.  Tarball attached.

===

Every Fedora package maintainer at Red Hat subscribes to the list and sets 
up mail filters to receive those patches that are relevant.  To heighten 
the whole "accountability" thing, the recipient of the patch:

1. sends an ack to the list upon receipt -- reply, "got it," takes 2 
seconds;

2. sends an "accept" or "reject" note when it's either accepted or 
rejected.

Simple enough?  Too simple?  Useful?

--g

-------------------------------------------------------------
Greg DeKoenigsberg || Fedora Project || fedoraproject.org
Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors
-------------------------------------------------------------