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

[Toshio Kuratomi]

On Wed, 2006-08-09 at 14:50 -0400, Christopher Blizzard wrote:
> It seems to me that it's not the fact that patches are getting lost, or 
> that people aren't uploading it.  Part of it is that it requires a human 
> to filter and maintainers are already overloaded as it is.  Why isn't it 
> that we can't have a system that keeps track of changes, let's anyone 
> try out a change without a hassle and then the patches that people are 
> using are filtered automatically to the top of a maintainer's queue? 
> Something like this would make people wildly more productive, connecting 
> developers, users and maintainers easily without the tools getting in 
> the way.

This would be interesting.  I'm interested in package foo.  I hit a
website (or run a script) and it tells me that seven patches have been
submitted for foo from the community.  I download patch #1, #2, and #3
through the website and it adds one user to each of those patches.
After a day I decide that #1 is horrible.  I go back to the website and
rate it horribly.  While there, I also rate #2 desirably.  #3 I haven't
had a chance to use yet so I leave.

Package maintainer hits the website and is told that patch #2, #5, and
#1 are the most popular downloads.  Patch #2, #3, and #5 are the highest
rated.  So he works on integrating the patches at the top of the lists
before the other ones.

So the big question is who will use it and will the statistics we get
back be relevant.  If the target audience for my distribution won't
touch a patch to save their life, then I'll be serving a whole other
audience if I follow these statistics.  OTOH, developers are not
necessarily different from end-users.  Knowing that fifty people are
interested in an issue as opposed to two has to count for something.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20060809/a6b18bb6/attachment.sig>