[mythtv] Decision on FFmpeg repository

[Peter Bennett]

On 05/16/2018 01:20 PM, Brian J. Murrell wrote:
> On Wed, 2018-05-16 at 12:45 -0400, Peter Bennett wrote:
>> I would like to get a decision on what to do about a couple of
>> FFmpeg
>> questions:
> I don't really have any skin in this game so take my opinions with a
> grain of salt, however...
>
>> - the FFmpeg website recommends using master for those who are
>> compiling
>> FFmpeg themselves. It states that the release branches are for those
>> who
>> rely on downloaded prebuilt packages
>> (https://ffmpeg.org/download.html#repositories).
> This doesn't really square for me.  I don't see why those compiling
> themselves are any different than those who get packages from packagers
> (read on).  Ultimately everything else being equal everyone wants
> stability.  But things are not usually equal so some trade off
> stability for bleeding edge because they feel the value is there, for
> them.  But others value the stability more and so give up on bleeding
> edge features.
>
> The master branch (assuming typical branching processes) of (most) any
> project is always going to be potentially less stable than release
> branches that don't constantly have things being committed to them and
> have been created at a time of recognized stability.  And as time goes
> on gain a record of stability.
>
> So is the above document suggesting that master is good (enough) for
> self-compiling people because they could (and would be willing to) be
> agile enough to jump forward if instability is determined?  If that is
> the reasoning, does that really fit here?  Isn't the MythTV project
> (particularly on a "fixes" branch) more like the (not-so-agile)
> packagers packaging for consumers?
>
> Cheers,
> b.
>
Hi Brian

You have valid points here. However my plan is that we will only bring 
in FFmpeg updates to the MythTV master branch. Only once that is stable 
would be create a new MythTV fixes branch. In our master branch, people 
should be willing to put up with some instability as we iron out 
problems. After bringing in a new version of FFmpeg we can, if 
necessary, cherry-pick FFmpeg commits that fix bugs that fix bugs which 
may affect us. We will never bring in a new FFmpeg version on a "fixes" 
branch.

Peter