[FFmpeg-cvslog] [ffmpeg.org]: r457 - trunk/src/download

[Reinhard Tartler]

On Sun, Jun 13, 2010 at 23:51:24 (CEST), Michael Niedermayer wrote:

> On Sun, Jun 13, 2010 at 10:05:42PM +0200, Reinhard Tartler wrote:
>> On Sun, Jun 13, 2010 at 18:50:01 (CEST), michael wrote:
>> 
>> > Author: michael
>> > Date: Sun Jun 13 18:50:00 2010
>> > New Revision: 457
>> >
>> > Log:
>> > The truth about 0.5.*
>> >
>> > Modified:
>> >    trunk/src/download
>> >
>> > Modified: trunk/src/download
>> > ==============================================================================
>> > --- trunk/src/download	Fri Jun 11 15:42:09 2010	(r456)
>> > +++ trunk/src/download	Sun Jun 13 18:50:00 2010	(r457)
>> > @@ -73,6 +73,9 @@
>> >  shed"</h2>
>> >  
>> >  <p>
>> > +The 0.5 branch is ONLY for distributions and not end users, it is over a
>> 
>> what are end users supposed to be? I don't expect any end user like my
>> parents to even know what a compiler is.
>
> end users are people using ffmpeg
>
>
>> 
>> > +year outdated and unsupported by us. SVN/GIT head is much better in every
>> 
>> what do you mean with 'support'? Diego and I are doing point releases,
>> so there *is* at least *some* amount of support available. 
>
> support means accepting, commenting, fixing and reviewing bugfixes,
> feature requests and patches. That is not being done and it would
> be a waste of time, time that could be better spend on svn head
>
>
>> 
>> > +respect including stability, bug count and security.
>> 
>> the release branches are definitly more 'stable' than trunk, as there
>> are a lot less chnages compared to trunk.
>
> i meant stable in the sense that they do what the user wants them to do.
> Not stable in the sense that they break/crash in the same way they did
> since a year, it was possibly a poor wording. But the way debian uses
> the term stable and unstable is even worse.
> dead and actively_developed are better terms for that.
>
>
>> The probablility that a change
>> in a release branch will break existing applications, require
>> recompilation, or similar (this would be "my" understanding of
>> "stability" is close to zero.
>
> i dont agree, changes done to svn head are done and reviewed by the
> authors and maintainers of the code.
> cherry picking changes by other people, even smart people has a considerable
> risk that it misses depending changes and that this leads to unexpected
> bugs.
>
>
>
>>  Maybe you meant to write something else
>> than 'stability'?
>> 
>> As for bug count, the set of bugs is not likely to increase over the
>> time in release branches.
>
> i disagree
> cherry picking changes without full understanding of the code can very
> easily introduce bugs that have never existed in svn trunk
> Interdependancies may or may not be known by the author during his
> commit but a year later surely noone knows it anymore.
>
> As examples, consider a muxer depending on a change to the internal
> timestamp handling or even just the change of a default value
> This can very easily lead to the generation of broken files and
> thus in some sense data loss. Even if this happens just once in a
> year or less often it could be a serious issue.
>
>
>> This is more likely in trunk, as only there
>> new features are integrated. If you wanted to say that since all
>> bugfixes happen in trunk and therefore, using trunk greatly increases
>> the chance to get a particular bug fixed, then I'd agree but think this
>> comment could be improved.
>> 
>
>> As for security, I wonder why do you say that trunk/ snapshots are more
>> 'secure' than release branches. For me, a security issue is always a
>> serious bug that needs to be fixed. Known bugs in release branches will
>> be fixed by the next point release. There is obviously a considerable
>> latency for such fixes to "propagate" to release branches, but I
>> wouldn't necessarily conclude that using release branches were "more
>> risky" to run than trunk.
>
> 1. There is a considerable risk security fixes are being missed by you
>    (yes its the fault of the commiter not marking it correctly but this
>     doesnt change it)
>    and the older a release becomes (in the when it was forked sense) the
>    higher the risk that fixes have been missed long ago.
>    A bad guy searching for sec holes has an eye for spoting them, he will
>    not miss them when going over the changes even if the svn log is poorly
>    written
> 2. The fewer targets there exist the easier is an attack, having 1 release
>    per year with just minor backports is easier to target than a
>    moving target like svn
>
>
>> 
>
>> Having said this, would you mind reverting the change until we have
>> found a less confusing wording?
>
> Feel free to suggest improvments.

I've now committed a version that addresses all the points you rised
above. It moreover avoids confusing terms but gives strong emphasis that
in general, using svn trunk is the right choice.

> It is important to the ffmpeg project that users primarely use svn
> so that issues are spot and corrected quickly that is when the
> developers still remember all fine details.
>
> And i hope my reply doesnt end up more inflamatory then intended

well, it is tempting, but I resist by answering it in short at the
bottom ;-)

> (note ive a headache ATM so id guess my politeness isnt at its best
>  thats unintended though)

Get well soon!

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4