[FFmpeg-devel] release

Robert Swain robert.swain
Fri Jan 30 15:20:56 CET 2009

2009/1/30 Luca Abeni <lucabe72 at email.it>:
> Diego Biurrun wrote:
>> On Fri, Jan 30, 2009 at 02:26:39PM +0100, Luca Abeni wrote:
>>> Diego Biurrun wrote:
>>>> On Fri, Jan 30, 2009 at 10:25:22AM +0100, Nicolas George wrote:
>>>>> Le septidi 7 pluvi?se, an CCXVII, Diego Biurrun a ?crit :
>>>>>> Just think about it, we throw out a tarball and then we can go wild
>>>>> Does that mean that, one year from now, people still using that tarball
>>>>> instead of the SVN head will be welcome on the mailing-lists and that
>>>>> bugfixes will be backported?
>>>> No, whoever wants to report bugs has to use the latest trunk version.
>>> Sorry, but this makes a release completely useless...
>> Are you volunteering to triage bugs reported against the release?
> No. But I did not volunteer to make a release too ;-)
> The real work with a release is not in packaging something. The real
> work starts after you release...
> Otherwise, here is the latest ffmpeg release:
> http://ffmpeg.org/ffmpeg-export-snapshot.tar.bz2
> Nect version will be released tomorrow.
>> The point of a release cannot be reporting bugs against it.  What you
>> say makes no sense.
> The point of a release is that users are provided with something they
> can use. If you release "ffmpeg v0.5" (or whatever you call it) and then
> you ask people not to use it (otherwise they cannot report bugs), you
> are just asking for more and more users complaining...

Diego: can you respond to this with the purpose of making a release if
we do not maintain it after it has been released? Otherwise what you
said seems to be a very negative comment to make for a release

If releases encourage us to do some bug fixing stints every so often
(one weekend a month?) then that's a good thing. I think if they
encourage us to do a bit of planning and organising of our goals, that
would also be good. While we may not conduct releases traditionally
(backporting all bug fixes, point releases containing batches of bug
fixes and/or security fixes with strict plans between releases, etc.)
I think it would be good to clarify what our goals are for releases,
what we're trying to achieve.


More information about the ffmpeg-devel mailing list