[FFmpeg-devel] [POLICY] Patches application threats

[Stefano Sabatini]

On date Friday 2008-10-31 18:32:32 +0000, M?ns Rullg?rd encoded:
> 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.

I still believe that that such a practice can still be useful in some
cases, for example when:

1) the patch has been thorouhghly discussed
2) more than one ping have been sent with no maintainer reaction
3) the patch is fairly trivial

In these cases I think the practice is not evil, since it decreases
the contributor frustration due to its work not being applied.

Most patches of mine belong to this category so maybe I misused of
this practice, sorry if this is the case, it wasn't my intention at
all to be unfriendly.

But I also agree that the application delay time should maybe be
longer than three days in the case the maintainer cannot reply for
whatever reason, also maybe every maintainer should decide for the
components he maintains, assuming he can actively maintains them.

Regards.
-- 
FFmpeg = Frightening Fostering Monstrous Powered Egregious Game