[FFmpeg-devel] Donations and what happens with them

[Hervé W.]

On 29/01/2011, Nicolas George <nicolas.george at normalesup.org> wrote:
> Le decadi 10 pluvi?se, an CCXIX, Jason Garrett-Glaser a ?crit :
>> But I saw this as just as much of a problem before the change, too.
>> Very often, you would have some problem X and some patch Y that fixes
>> it.  Patch Y isn't perfect, and doesn't solve the problem in the best
>> possible way.  Reviewers suggest or insist that patch Y do complex,
>> harder thing Z to solve the problem better.
>>
>> It never happens, and problem X remains.
>
> I agree with this analysis, the policy should be fixed with that regard.
>
> I think a patch should be allowed to be applied if:
>
> - it improves something and does not make something else worse;

This one is important. Trying to get the reviewer to agree to this
point is step one. And "does not make something worse" should be
defined as "does not break anything" rather than "it is an ugly hack
that does not fit into the design".

> - the submitter sincerely thinks that doing it in a better way would be too
>   much work for him;
>
> - no one volunteers to do it in a better way quickly, or said volunteer is
>   not quick enough;

I'm less enthusiastic about these two, but I can see how that might happen.

> - the patch has a visible (greppable, if in comment) reference to the
>   discussion on how to do things right.

Good idea.
I think trying to find a 2nd reviewer should follow showing that it
doesn't break anything.

If 2nd review agrees with 1st review, it becomes a matter of what is
the goal; More working options and files for the users or good clean
easy to maintain code.
If I recall correctly, the plan is to have more timely releases.
Releases would be served by having more situations that work,
regardless of the hacks employed (after all, HEAD is where the real
development happens, not branch 0.x.y ).
So how about this:
0) difference of opinion between reviewer and patch developer
1) show/get to agree that it improves the situation and doesn't break
anything. If that's not enough:
2) get a 2nd reviewer (and try step 1 again)
3) stop all flames and have the reviewers agree with putting it on the
next-release branch and place a visible (greppable, if in comment)
reference to the discussion on how to do things right both in the
release-branch and HEAD.

Yes, checklists suck. But flamewars and/or having patches left to
bit-rot suck even more.


On 29/01/2011, Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
> Having committ right simplifies the commit of uncontroversial changes
> (e.g. typos, trivial fixes), with git is a simple matter of git commit
> -p and some rebasing, having to pass through the send-email+review
> chain looks like unnecessary burden.

If it's trivial or a typo, review shouldn't be much of a burden.


-V