[FFmpeg-devel] release feedback

[Diego Biurrun]

On Sun, Mar 15, 2009 at 02:21:15PM +0000, Robert Swain wrote:
> On 15/3/09 11:56, Diego Biurrun wrote:
> > On Sat, Mar 14, 2009 at 09:16:32PM +0000, Robert Swain wrote:
> >>> 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.

Most people seem to survive a few months without updating their software.
I don't think it's a problem to tell them to wait some time or use trunk
as long as the wait schedule is dependable.

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

We could pick some distro and synchronize with them if need be.

> 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 think going from no releases to two releases per year is a start.
Let's not get carried away too much, getting another release out in
half a year will be difficult enough.

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

Yes, please help keeping stuff synchronized.  Manually getting it
current was a thankless chore.

> >> [.. 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.

If we have a fixed timeframe, maintainers could work towards getting
their code into release-ready shape in a timely fashion.

Diego