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

[Christopher Blizzard]

Greg DeKoenigsberg wrote:
> 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?

Nope, too high overhead in my opinion.  This is going to sound rough but 
usually when you set up -patch mailing lists or send things to bugzilla 
it's often sent to the grave.  It's too easy to ignore and too hard to 
process.

Here's one possible vision.  Imagine that you have your source tree. 
(Note that I didn't say tarball) and it was easy to know exactly what 
patches or changes were pending to the source tree.  You knew who owned 
them, who thought they were cool or they sucked and it was _super_ easy 
to generate a build with that change.  i.e. you could generate a build 
automatically with the click of a single button.  If a change spanned 
more than one package - and they often do - that there was some kind of 
linkage between a set of changes in a set of packages.

Trying it out would be done with a single button click and when you were 
done testing you could go back, also with a single click.

What I'm suggesting here might be seen as crazy, but I don't think it's 
anywhere outside of the realm of what we can do today.  You just can't 
really do this with rpm and bugzilla and mailing lists.  The system and 
pieces are too layered and sparse.  And they certainly aren't designed 
to make it easy to connect developers with their end users.  Nor do we 
have systems that really enable participation.  At best what we have is 
a system that lets you leave a note in the suggestion box.

--Chris