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

Michael Niedermayer michaelni
Sun Jun 13 23:51:24 CEST 2010


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.

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
(note ive a headache ATM so id guess my politeness isnt at its best
 thats unintended though)


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20100613/46126652/attachment.pgp>



More information about the ffmpeg-cvslog mailing list