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

Christopher Blizzard blizzard at redhat.com
Wed Aug 9 19:47:14 UTC 2006


Toshio Kuratomi wrote:
> 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.

Yes!  This is the kind of thing that I've been thinking about.  The best 
thing that google ever did was to turn everyone into a filter.  A 
thousand little filters and all of a sudden you have a system that 
learns.  I think that we haven't learned from this, and we certainly 
haven't tried.

Although what you're talking about is still script driven.  My vision is 
something that lets you explore what's going on visually and picking and 
choosing what you want.  You could see what a person is working on 
(follow a leader - think linus or davej or ajax) or you could see how 
someone who is awesome at integration has done to fix a few packages. 
i.e. "this set of patches to hal, dbus and the kernel together fix the 
brightness keys on my macbook[*]."  And trying that out (or untrying!) 
should be so easy that anyone can participate.  Or you want to backport 
it to an older release and connect the two sets of changes?  Our current 
tools aren't linked, so this is pretty hard to do.

There's also another level that it would be good to connect on. 
Hardware.  Laptops in particular.  If a patch was useful on a particular 
piece of hardware, why couldn't you tell everyone who had one that they 
would be interested in it and to try it out?  Think about how many times 
we've had to say "here, try this patch and let me know if it works for 
you or breaks your shit?"  And you never hear back because it takes 
hours to try out a patch.

--Chris

* I had to sit down with DavidZ and have him set up a lot of this stuff. 
  He generated a patch which sits on my hard drive.  It's a pita for me 
to make my own hal build so there it sits.  With my screen at a single 
brightness, wasting battery.




More information about the fedora-advisory-board mailing list