[FFmpeg-devel] release feedback

[Robert Swain]

On 14/3/09 19:06, Diego Biurrun wrote:
> So the release is done, time to think what went good and bad about it.
>
> In the outside world the feedback was overwhelmingly positive.
> Everybody seemed to be delighted to see an FFmpeg release.  Some
> people even saw fit to express their gratitude in private.  Your
> kind words are very much appreciated.

Indeed. Thanks go to the people who gave us thanks. :)

> The target audience for this release were distributions and projects or
> companies reusing FFmpeg.  From what I have heard they received exactly
> what they wanted.

 From whom have you heard?

> As for the release process, it could surely be improved.  It was bad
> luck that roundup broke at the time we wanted to have the bug fixing
> weekend.  I had hoped that more people would be motivated to work on
> fixing bugs during this weekend.  Some actually did, but the interest
> was not overwhelming.

At least the website got a face lift. ;)

> The freeze took longer than planned due to the issues mentioned above.
> The next time around, I would not extend it, but just the two originally
> designated weeks should not slow down development in any way.  AFAICT
> what was stopped during the freeze was just merging, not development.

We had an unfortunate run of events up to the release that delayed it. 
Personally, I think the feature-freeze should have either been more 
strongly enforced, or we should have branched earlier. The problem with 
branching earlier is that there is no sole focus on fixing bugs in trunk 
and that bug fixes have to be ported to the branch which means extra work.

It seems the hosts of mplayerhq.hu (I know this is under our control), 
ffmpeg.org and roundup are all have their issues at the moment.

One item of note that is not related to this thread: while Attila is an 
excellent server administrator and provides us with a very good server, 
the response time for the server 'failure' we experienced severely 
stunts development.

Hopefully that was very rare downtime so it won't matter, but losing the 
mailing lists halts the vast majority of FFmpeg's (and MPlayer's) 
development.

I understand Attila has his own daily activities to deal with, but in 
terms of hosting support, we could really do with something with a 
faster turnaround time for such issues. Is there anything that can be 
looked into to address this?

Attila, this is not a dig at you, but I expect you can understand my 
reason for pointing this out.

> One question that remains is whether we should repeat this regularly or
> at all.  Given the positive feedback, I believe we should institute a
> regular release schedule.  I envision time-based releases every 3 or 6
> months.  After some thought, 6 months sounds preferable.  It is less
> disruptive to the development process and a schedule that seem to work
> well in a lot of other FOSS projects.

I would like 3-monthly releases.

> Feature-based releases seem to be constantly hampered by feature creep.
> There will always be a feature or bug fix that just has to go in and the
> release date can thus get pushed back continuously.  This is partly due
> to the fact that the next release will be a long and unforeseeable time
> in the future.

Unless we have ruthless and omnipotent release management (very unlikely 
in this community - we are not a dictatorship), I don't think attempting 
feature-based releases is the way for us to go at all.

> Time-based releases with a regular and dependable schedule solve this
> problem.  I believe it is the way to move forward.

I also want time-based releases, but with a focus on the status of the 
code at the time. So, as noted, I'm with Baptiste on this in most 
senses. I'll wait to see what his comments to before I pledge full 
allegiance, but here are my thoughts:

The basic idea from my perspective is to have an amalgamation of time- 
and status-based releases. That is, every N-months (I vote for 3-months) 
we try to do a release. We ask maintainers, or evaluate ourselves, what 
the statuses of the various parts of FFmpeg and its libraries are and 
choose which svn revision to cherry pick for each isolated piece of code 
as being the most stable and feature-full.

Before you scream that this is impossible to maintain, please read on.

In most cases, this should be the current HEAD revision of trunk, but 
there may be instances where some (de)muxer or en/decoder has had some 
work in progress code committed to it that doesn't break it entirely but 
does introduce some regressions not covered by whatever regressions 
testing we have available but that have been noticed by users/developers 
who are testing the branch.

In the long term it is obviously desirable to cover all possible 
regressions in our testing platforms and fix any regressions. In the 
short term time frame for making a release, fixing the regression may 
not be feasible. As such, rather than use the code that has been 
introduced since the last release, the last known 'best-status' code 
should be used for the pending release.

This would be achieved by using some older revision of the very isolated 
code (that's why I talk about containers and codecs, because they're 
isolated bits of code).

 From what I perceive, this is actually what we did for 0.5 as we had to 
back out a few changes that had been made in trunk at the point at which 
we branched to make the code base feasibly releasable.

The point is not to have very old versions of code for certain things in 
the releases, the point is to have the best recent code in the releases. 
Doing this should also highlight areas of concern for maintainers.

> The other question is ongoing support for releases.
>
> I think we should just port security fixes to the release branch.

I think this is a reasonable bare minimum.

> IMO continues updates to the release branch are a workaround for a
> release that is too long and/or too unpredictable.  The correct solution
> is to find a rhythm that suits everybody.

I agree. I don't think we should backport features at all. They should 
wait until the next release/until they're ready.

> Otherwise precious manpower that could be put to better use improving
> the trunk is bound by release work and - IMHO - wasted.
>
> There is one issue for which I would make an exception right now:
> LGPL libswscale.
>
> Making libswscale compile as LGPL would make it usable for a broader
> audience of projects / users that cannot use it as GPL.  Furthermore,
> the README in the release is already ambiguous about the issue and
> it just requires adjusting one or two #ifdefs, so there cannot really
> be any regressions.

Do you just intend to backport making libswscale compile under LGPL or 
also rip out imgconvert? I'm guessing the former. If so, I think that 
would be reasonable. If not, I don't.

Regards,
Rob