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

[The Wanderer]

(Sorry for the delayed reply; I'm probably getting unnecessarily
neurotic.)

M?ns Rullg?rd wrote:

> The Wanderer <inverseparadox at comcast.net> writes:

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

I do remember quite a few cases where the "will apply in X days if no
objection is heard" came at the same time as the patch itself. However,
now that I think about it, those may have been for files which had no
listed maintainer, which would of course be handled differently.

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

Conceded. The question then becomes at what point that approach should
be resorted to.

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

And if no one else has (or appears to have) the relevant knowledge, and
there are no apparent candidates for replacement maintainer?

If memory serves, this technique was first used (that I saw) A: by Diego
on the MPlayer lists and B: for files which in fact had no maintainer,
as a way of getting consensus approval for them rather than leaving them
in Limbo until such hypothetical time as a maintainer might appear.

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

Hmm.

It occurs to me that the tone of the objections is probably part of what
I am reacting to. All of your objections which I remember seeing posted
seemed to be to be somewhat belligerent or antagonistic in tone, and the
use of the (objectively perhaps applicable) term "threats" probably did
contribute to that. I would probably have found objections more along
the lines of "please don't do that kind of thing for the build system"
to be less hostile and/or offensive, to the point where I might not even
have remembered your making them. Did you by any chance do so?

I suspect that I have something of a hair-trigger negative reaction
these days to anything which I perceive as authoritarian issuing of
orders, as opposed to e.g. making of requests, and it is entirely
possible that that is a major reason I reacted the way I did.

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

Acknowledged and agreed. (Though, in this case, the "few days" had
already passed...)

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

All of those things are true. None of them seem to address the problem;
at least two of them may in fact be part of the problem.

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

I would still consider that a "blanket ban" - it blankets only the build
system, but it's still across-the-board and unconditional within that
category.

It also imposes the overhead for people who might make such a post of
checking "does this patch touch any areas which are under such a ban?",
without any clear indication (except mailing list history) of what those
areas might be; the most practical way of not violating such a ban would
be to never make such posts at all, which would effectively eliminate
the practice in far more than just the build system.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.