[FFmpeg-devel] policy on "necro-bumping" patches

Michael Niedermayer michaelni at gmx.at
Tue Sep 15 19:47:44 CEST 2015


On Tue, Sep 15, 2015 at 12:47:35PM -0400, Ganesh Ajjanagadde wrote:
> On Tue, Sep 15, 2015 at 10:54 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Tue, Sep 15, 2015 at 08:48:33AM -0400, Ganesh Ajjanagadde wrote:
> >> On Tue, Sep 15, 2015 at 6:54 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> >> > Hi Ganesh,
> >> >
> >> > On Mon, Sep 14, 2015 at 10:27 PM, Ganesh Ajjanagadde <gajjanag at mit.edu>
> >> > wrote:
> >> >
> >> >> Hi all,
> >> >>
> >> >> What is ffmpeg's policy on "necro-bumping" old patches? Or more
> >> >> precisely, what is the policy of requesting a patch to be merged where
> >> >> all objections raised have been addressed via discussion/updated
> >> >> patches, and which have not been merged in over 2 weeks due to unknown
> >> >> reasons?
> >> >>
> >> >> In particular, there are 2 patchsets I would like to get merged:
> >> >> 1. This I consider an important patch, simply because it solves a trac
> >> >> ticket labelled as "important": https://trac.ffmpeg.org/ticket/2964,
> >> >> which also contains links to the patches. A lot of discussion went on
> >> >> around it on the mailing lists, and it is supported strongly by
> >> >> Nicolas and me. Michael seemed initially hesitant but later became
> >> >> convinced of (at least one of the set's) utility, and one of the
> >> >> patches was applied. The only objection I recall was from Hendrik,
> >> >> which was addressed by Nicolas in a follow-up.
> >> >>
> >> >> 2. This I consider much more trivial, but in this case there are no
> >> >> remaining objections. However, I still consider it important enough
> >> >> for a request to re-examine, as I am doing here. The patchset is more
> >> >> recent, https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177794.html
> >> >> and https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178700.html.
> >> >
> >> >
> >> > Trivial patches can be merged after 24-48 hours if there's no objections
> >> > outstanding. For more elaborate patches, poke anyone for review if you feel
> >> > it would be helpful.
> >> >
> >> > In both cases, having push access yourself will hurry this along (i.e. you
> >> > really should get push access), but in this case I will push later today.
> >> > If you don't want push access, poke one of us on IRC to do the push for
> >> > you, or bump the original email with a "poke" or "ping".
> >>
> >> Thanks. Patches for 2) needs work, and I will be posting it soon.
> >
> >
> >> Patch for 1) should be ok (it was reviewed by Nicolas, and Michael
> >> seems ok with it like I mentioned).
> >
> > there where a few patches, iam not exactly sure which are left and
> > what effects they have
> > What i objected to and still object to is to cause the terminal to
> > be messed up in the most common default configuration in linux
> > (that is with bash) when ffmpeg crashes (either in a naturally/naively
> > written script or from the command line)
> > Iam not sure th last patches still cause this or not
> 
> Don't know what you exactly mean by a naturally/naively written
> script, and an example would be very helpful. I can say for certainty

naturally written == a script that does not contain a explicit
workaround for this issue
One would only add a workaround once one has been hit by a bug or knows
about it and searched and found a workaround.
The users time and convenience matters, we should not inconveience
many people by this.


> that fate and its associated scripts will not suffer from this issue,
> simply because of the -nostdin flag that was added in one of the
> patches (which has been applied). The question that remains is whether
> to apply: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176481.html
> or not.
>

> The point Nicolas raised is that no matter what we do, there exist
> quite reasonable ffmpeg invocations that can mess up the terminal
> (patch or no patch).

this is true, but reasonable is not the same as "used alot in practice"
something can be reasonable and used alot or it can be reasonable and
used very rarely


> All the patch does is remove a heuristic that
> does not even work in all cases (which is impossible unless shell
> configuration is changed with just 1-2 lines). It also improves
> usability by fixing #2964.

no heuristic works in all cases, thats the nature of heuristics
for example our file format probing is all heuristics, not every
file starting with "RIFFAVI" is a avi file  ...

if the heuristic doesnt work well enough, then it should be improved
if that is possible

if the bug is belived to be else where (shell, config whatever)
it should be fixed there so that future default setups do not need
this heuristic anymore
The heuristic should be kept as long as the alternative inconveiences
more people
I assume that the heuristic inconveiences fewer than the alternative
of nothing. Is there a reason to belive that this is not the case ?


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150915/127e55d2/attachment.sig>


More information about the ffmpeg-devel mailing list