[FFmpeg-devel] maintainer duties (was: Re: [PATCH] fix speex sample)

[Michael Niedermayer]

On Thu, Apr 09, 2009 at 04:15:01PM +0200, Diego Biurrun wrote:
> On Thu, Apr 09, 2009 at 03:48:05PM +0200, Michael Niedermayer wrote:
> > On Thu, Apr 09, 2009 at 09:33:26AM +0200, Diego Biurrun wrote:
> > > On Wed, Apr 08, 2009 at 06:30:56PM -0700, Baptiste Coudurier wrote:
> > [...]
> > > Now while we're speaking of maintainer duties...  I agree with your
> > > position much more than I agree with Michael's, but I have to point out
> > 
> > i think we should clarify once and for all what duties a maintainer has
> > because people apply worse than double standards here
> > and because this is a matter very critial to keeping the project functioning
> > 
> > Theres no question that until recently a submited patch was reviewed,
> > and when suggestions for improvments where provided, the patch author
> > then had to fix the patch if he wanted it in svn or explain why the
> > suggestions where undesireable.
> > 
> > Do you propose that maintainers should fix patches themselfs now?
> > Or do you propose that patches failing review should still be commited?
> > Or do you propose not to review patches?
> > 
> > If none of above, then where do you disagree with me?
> 
> I think maintainers should (in descending order of priorities)
> 
> 1) review patches,
> 2) fix bugs and
> 3) implement missing features

agree and i still have patches to review ...


> 
> in the areas they maintain.  Of course since especially 3) can take
> arbitrary amounts of time, things have to be prioritized according to
> the factors fun and importance.
> 
> Patch review can take several iterations.  Sometimes it's quicker to fix
> up patches or implement alternatives directly instead of having the
> patch submitter do it.  In these cases I think it's preferable for the
> maintainer to do the coding unless one expects the patch submitter to
> learn some valuable lesson that may pay off down the road.
> 

> I'm under the impression that you could often fix issues in much less
> than the time it takes you to write reviews.  In other words, I believe
> you could work more efficiently if you skipped a review every once in a
> while.

i try to test changes before commiting so while it may be a 1 line change
testing will in general take more time than writing a reply


> 
> Also, if patch submitters are unresponsive IMO maintainers should fix up
> and commit patches themselves.

If they have the time ...

also iam in no shortage of such patches, theres a huge one from netgem and
probably more from other ffmpeg users that should be looked over and fixed,
and that doesnt speak of patches that where submitted and never fixed by their
authors ...

So even here theres a huge selection of patches that need a helping hand,
and what that means is if i find the time & will to work on this, chances
are it will be a patch that iam sure noone else will pick up and that is
likely little work per gain. Chances are that would not be a patch another
ffmpeg developer droped but rather one like netgems that for some parts might
need little more than spliting hunks appart and commiting.

And if someone wants to help here, this would be tremendously welcome, i mean
adding a patches directory to svn and commiting patches like netgems in there
and letting people then split it, drop bad and alraedy applied parts and so
on.
The example of netgem is one where the patch is almost too large for a single
person to do it so doing it in svn seems like a good idea ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090409/8f093f38/attachment.pgp>