Sun Apr 15 22:41:18 CEST 2007
On Sun, Apr 15, 2007 at 10:27:22PM +0200, Stefan de Konink wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> Rich Felker schreef:
> > On Sun, Apr 15, 2007 at 11:07:59PM +0300, Ismail D?nmez wrote:
> >> Well imho also regressions are worrisome, recently (at least for me) frame
> >> rate detection and also audio bitrate detection got worse. Fixing regressions
> >> would be a priority. On the other hand a fork might just make the whole
> >> situation worse (unlike X.org fork from XFree86 where all-1 developers were
> >> involved in the fork which is not the case here).
> > The last thing a fork would do is fix regressions, I suspect... If
> > there are regressions, they need to be fixed, and people (Michael
> > included) need to be more careful about committing code without
> > thinking about it thoroughly and understanding it.
> Wouldn't a branch like named: 'incoming' not fix the mailinglist
> patches, and 'other users opinions' ones and for all?
> If this specific branch was there to show the code is useful and used or
> to 'not forget the code exists'. ffmpeg-trunk can be clean, pretty, fast
> (the way it should be) and incoming can be ugly.
> When a person wants to incorporate 'incoming' in 'trunk' it needs to go
> trough the approval process. But then it is known that the functionality
what is "incoming" supposed to be?! who should decide what gets commited
a branch like "baptiste" would at least make sense but "incoming" does not
applying patches without review will break the branch after the 3rd patch
so it likely wont even compile and with review theres no difference to
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel