[FFmpeg-devel] release feedback

[Robert Swain]

On 15/3/09 11:56, Diego Biurrun wrote:
> On Sat, Mar 14, 2009 at 09:16:32PM +0000, Robert Swain wrote:
>> 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.
>
> A day of downtime every other year or even less is quite a good service
> and does IMO not noticeably affect development.

Indeed, OK.

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

FFmpeg development is very rapid. If we space releases too sparsely, we 
(the developers) will have less faith in releases and this will transfer 
into telling users to use trunk more due to the previous release being 
outdated. I think this devalues releases.

Many popular distributions have ~6 month release cycles that are not 
synchronised. Using the same level of granularity, I think it would be 
quite easy for one of our releases to miss their package freeze windows. 
As a lot of packages depend on FFmpeg, this may have a significant 
impact on the functionality, bugs and so on that are apparent in a wide 
variety of packaged software. Maybe this is a non-issue, I'm not sure.

My gut tells me that 6 months is a big gap and 3 months less so while 
still being a reasonable amount of time for a lot of changes to be made 
in trunk.

I understand that more frequent releases means increased work load, but 
the significant delays for 0.5 were related to finding regressions and 
fixing them and updating documents. We should really keep on top of 
documentation as we go along and I'm sure you'll agree with this Diego. 
After efforts from Diego, Justin and others just before the release, 
this should also consume less time in future.

I expect we could work with Edward Hervey from GStreamer to get the 
results from his regressions tests being fed back to us in a more 
streamlined fashion. Maybe we could donate some CPU time to his testing. 
I'll probably look into this when I get my new machine. It may be good 
for us to see what regressions tests the VLC team run and try to 
collaborate with them in appropriate areas too.

>> [.. long description ..]
>>   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.
>
> So in summary this means no process changes.  Pick a revision to base
> releases on and identify regressions.

Do you think the potential release process policy of requesting feedback 
from maintainers as to the status of their code as well as looking at 
our regressions suites is reasonable? I think it gives us a better base 
for quality control considering the limited scope of our regressions 
tests for the moment.

>>> 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.
>
> Just the former of course.

Then I have no objections as it is a minor change and does not change 
functionality. Baptiste?

Regards,
Rob