[FFmpeg-devel] maintainer duties

[Robert Swain]

On 9/4/09 15:15, 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:
>> [...]
>>> 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

Good idea.

>> 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?

Sometimes. See below.

>> Or do you propose that patches failing review should still be commited?

No.

>> Or do you propose not to review patches?

No.

>> 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
>
> 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.

I would say that the above prioritisation/ranking should be weighed 
against importance of the issue, time available/time taken to complete 
and finally personal enjoyment.

Accepting/taking maintainership of files incurs responsibility upon that 
person and I think that the importance of an issue should be a primary 
factor in delegation of time. If items have equal importance, address 
those that take the least time first. If items have equal importance and 
take equal time, do the ones that are of most interest first. Of course, 
importance is often subjective and I'm not sure how to fairly consider 
the importance of any issue.

Suggested approaches for addressing importance:
- maintainer's personal evaluation of importance
- evaluate importance against project-wide goal
- roll a number-of-issue sided die

> 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.
>
> Also, if patch submitters are unresponsive IMO maintainers should fix up
> and commit patches themselves.

I agree with Diego on this point. If patch submitters submit more than 
one patch, it may be worth being more rigorous in the review of their 
submissions.

If a patch submitter is only going to submit one patch, applying the 
same rigour to them when they often don't have significant time to 
direct to the submission.

In the past, this has lead to extended arguments about the pedantry of 
the reviews and hence wasted time. It is in these cases that I think, 
after evaluating importance etc., a maintainer should pick up such 
patches and deal with them themselves.

Regards,
Rob