[FFmpeg-devel] release feedback
Sun Mar 15 18:25:20 CET 2009
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.
More information about the ffmpeg-devel