[FFmpeg-devel] [PATCH] Check for bugged make
Måns Rullgård
mans
Fri Oct 31 19:32:32 CET 2008
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
More information about the ffmpeg-devel
mailing list