[FFmpeg-devel] maintainer duties
Thu Apr 9 16:37:34 CEST 2009
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
>> 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?
>> 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
> 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
> 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
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.
More information about the ffmpeg-devel