[Ffmpeg-devel] [RFC] ffmpeg-windows mailinglist?

[Diego Biurrun]

On Wed, Aug 02, 2006 at 07:53:20AM -0400, Augie Fackler wrote:
> 
> On Aug 2, 2006, at 5:38 AM, Diego Biurrun wrote:
> 
> >On Tue, Aug 01, 2006 at 09:09:21PM -0400, Augie Fackler wrote:
> >
> >Do I understand right that you are complaining that some patch sat in
> >the queue without getting a response for 3 days ?!?
> 
> Not precisely - your turnaround on most patches is 24 hours, so the  
> general assumption *I'd* make would be that a patch got lost in the  
> overall noise

I do make an effort to review patches as quickly as possible, but of
course I cannot guarantee any sort of turnaround time.  And I do try to
review *all* patches in my area.  I believe this goes for all FFmpeg
reviewers.  If there is no reaction after a week or so, just send a
polite reminder.  Explaining your patch some more always helps.

> >May I remind you that reviewing is unpaid, unceremonious and - as this
> >mail exchange proves - extremely underappreciated work.  Look at  
> >how few people do it.  I'd say the ratio of committers to reviewers is  
> >about 10 to 1.
> 
> Relax. I've reviewed patches for another project, it's generally not  
> fun and not rewarding.

OK, if you understand the situation then all is well.  I have to say
that I *do* think reviewing patches is rewarding as sometimes the people
you review patches for end up being regular devs on your project.
However reviews are generally underappreciated and not done by enough
people.  I believe this is a central problem for open source
development, reviews are a bottleneck.  No, I don't know the solution.

> >I believe you have things backwards.  Reviewers should not go out of
> >their way to accomodate patch senders, it should be the other way
> >around.  Reviewer time is just that much more valuable...
> 
> When I have a patch that would deliver theoretically desirable  
> functionality, I am frequently tempted to just rewrite it myself, but  
> I lack time for that, so usually I'll make a brief description of why  
> the patch is rejected and include a general idea of what could be  
> done to fix that if so requested (when I asked how something should  
> be done here, I was told to "write a patch, submit it, and if it's  
> not what we want it'll be rejected.)

I think patches are generally rejected with an explanation.  Maybe that
explanation could be better.  If it isn't, just ask, I'm sure all
reviewers around here will be happy to outline their proposals in more
detail if there are hopes of stuff getting implemented that way then.

> All of this is neither here nor there at this point, because I have  
> the description of why the patch below is not wanted, and it should  
> be fairly easily fixed.

That's excellent news :)

> >It's a great pity IMO that most people seem to be content with  
> >coming up with a hack that makes their machines work but seem
> >unwilling to work on a more general solution ...
> 
> The more general solution was never previously explained in a way  
> that was clear to me. As it is now, I understand the problem with the  
> patch and should be able to put time into cleaning it up properly.

I hope we shall have all of this behind us soon then.

Can we come to some sort of consensus here?  I propose that patch
senders do not take rejections personally or as dismissals of their work
and on the other hand FFmpeg reviewers make an attempt to explain the
reasoning behind patch rejections in a clearer fashion that points in
the way of acceptable solutions.

Diego