[FFmpeg-devel] [PATCH] Check for bugged make

[Måns Rullgård]

The Wanderer <inverseparadox at comcast.net> writes:

> M?ns Rullg?rd wrote:
>
>> Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
>> 
>>> I'll apply at the end of the next weekend if I hear no objections.
>> 
>> You will do no such thing.  I have already said that any changes to
>> the build system need my explicit approval.  Please cease making
>> these threats.  I find it quite unfriendly.
>
> I find it a little bewildering (and possibly somewhat unfriendly) that
> you interpret these as threats. They have been standard-use boilerplate
> the entire time I've been watching MPlayer and FFmpeg development, and

This type of threats have seen occasional use for a long time.
However, in the last year or so, they have become ever more frequent,
to the point where I am now thoroughly annoyed by them.  Not only has
the number increased, the time from patch to threat has steadily
decreased, and is now down to a mere couple of days.

> are an apparently highly useful - perhaps even indispensable - tool for

I do agree there are instances where such an approach is probably the
best course of action.  It should, however, be an exception, not the
rule.

> avoiding having patches lie there indefinitely neither approved nor
> rejected; I seem to recall that they have led to the takeover of
> maintainership (when a previous maintainer had left without fanfare) on

That is a prime example of when *not* to deploy threats of this sort.
Code being abandoned by its maintainer is not an open door for patches
to be applied without approval; it is a call for a new maintainer.
Until a new maintainer is appointed, patches may be approved by
someone else with the relevant knowledge, or they will simply have to
wait.

> at least one occasion. You are the first person I remember having seen
> treat them as at all unusual, and I do not recall having seen any hint
> of your doing so until very recently.

I have put up with it for a while, but I am tiring of constantly
rushing to veto patches that otherwise will get applied without
approval.

> Why do you find them objectionable - particularly given that it's very
> easy to say "no" in any given case - much less consider them
> threatening? Why did you not do so before?

It is the need, not so much as the act, to say "no" to which I object.

> How would you recommend A: ensuring that patches which have been
> submitted and received no response are not ignored, and

Firstly, a few days before a response is perfectly normal.  Secondly,
the traffic volume on the mailing lists is high enough that a patch
can easily be missed, so a friendly ping before threatening to commit
is in order.

> B: not leaving submitters of such patches in limbo with no idea
> about whether or not their patch has even been looked at? Simply
> pinging is not effective in all cases; treating a long enough lack
> of reaction as unanimous consent, with an advance warning such as
> this one that that is what is being done, does seem to be enough.

A lack of reaction could mean just about anything.  Treating it as
unanimous consent would be a mistake.  It could equally well indicate
that nobody cares about the issue enough to look at the patch; the
patch could still be riddled with bugs.

> (There are arguments against it in many cases, of course, but I
> don't see how they're enough to justify a blanket ban on the
> practice...)

I am not trying to impose a blanket ban.  I am only placing a ban on
this practice for build system related changes.

-- 
M?ns Rullg?rd
mans at mansr.com