[Ffmpeg-devel] Re: Advocating periodic releases

[Dana Hudes]

Michael Niedermayer wrote:
> Hi
>
> On Fri, Oct 06, 2006 at 03:17:43PM +0200, Ulrich von Zadow wrote:
>   
>> Dana Hudes wrote:
>>     
>>> Tim Allen wrote:
>>>       
>>>
>> Given that the ffmpeg project doesn't seem to be interested in releases,
>>     
>
> no, we lack someone doing releases ...
>
>
>   
>> I can understand the desire to be independent of the ffmpeg
>> infrastructure. However, sourceforge has had serious stability and speed
>>     
>
> ffmpeg releases will be released primarely on mplayerhq and will live
> as branches in svn (or maybe some more advanced version control system 
> at some point in the future)
>
> idependant releases done outside of our control and our quality standards
> are perfectly ok but they are well ... independant and not ffmpeg releases
>
> [...]
>   
With all due respect I would find it very confusing to have releases in 
the same repository as development. That may be how you like to do 
things and you have every right to that opinion but my professional 
configuration management experience screams no!!!. I have no objection 
in principle to the use of the svn *server* at mplayerhq, but release 
are not development and in a proper environment developers do not have 
privileges to check things into the release tree.

 Rather, they submit release candidate code to the CM team and if it 
passes whatever QA/test then it gets checked in as a part of a release 
candidate or development and released to see if there are any issues for 
which we don't have tests (and for the porters to compile on various 
environments; it is, for example, not simple for me to get ahold of a 
Mac OS X machine and at that its a Powerbook not an intel Mac....and 
forget about BeOS AIX IRIX ....I don't have current MS Visual Studio 
either and t some point even if i have access to build it'd be nice to 
have someone else looking at e.g. cygwin). any issues that come up we 
try for simple fixes otherwise we  document the issue in the release 
notes as a known bug and possibly revise the test suite so that future 
releases will not pass with the bug. Until we have a fix we don't 
include the test obviously.