[FFmpeg-devel] [RFC] Releases

[Alex Converse]

On Mon, May 31, 2010 at 11:41 AM, Michael Niedermayer <michaelni at gmx.at>wrote:

> On Mon, May 31, 2010 at 04:17:35PM +0200, Reinhard Tartler wrote:
> > On Mo, Mai 31, 2010 at 04:48:06 (CEST), Michael Niedermayer wrote:
> >
> > > On Mon, May 31, 2010 at 12:12:50AM +0200, Diego Biurrun wrote:
> > >> On Sun, May 30, 2010 at 11:15:41PM +0200, Michael Niedermayer wrote:
> > >> >
> > >> > I think we should do releases more often than we did historically or
> > >> > not at all. Otherwise everyone will use very outdated ffmpeg&libav*
> > >>
> > >> I can understand that you want to see people use the latest and
> greatest,
> > >> but for some strange reason people just have their own priorities that
> > >> are at odds with yours/ours.
> > >
> > > both users and developers alike want the latest and greatest, its
> distros
> > > who partially want a slow pace. Which is understandable but not in our
> > > nor our users interrest.
> >
> > In the way as you write it here, this is wrong and in some ways (not
> > necessarily as you write it here but in other mails) blunt, because your
> > sentence implies that distro users would not be 'our' users.
>
> Then you misunderstand what i meant with distros.I consider distro users
> surely as our users. With distros i only meant the package maintainers and
> people in charge of distros, not their users.
>
>
> > No distro
> > *wants* slow pace;
>
> I disagree, debians very rare stable releases may be argued to be
> unavoidable
> but their choice of not updating packages except for security reasons in
> stable between is a concious choice aka "want".
>
>
> > their job is to *integrate* software packages in a
> > way that they fit together.  Since you seem to like picking on Debian,
> > let me list the *61* packages (with versions) that link against Debian's
> > system FFmpeg, which is taken from the ffmpeg-0.5 branch [I've listed
> > source packages that build-depend on libavcodec-dev, this might be
> > slightly inaccurate]:
> [...]
> > I expect that there will be a few more packages in addition in ubuntu.
> > Anyway, in order to get a debian stable release out, *all* of these
> > packges need to agree on a single version of ffmpeg, and that's the
> > purpose of the system ffmpeg package.
> >
> > And no, from a security POV static linking or embedding ffmpeg in all
> > (or most of thesse packages) is not an option.
> >
> > >> [...]
> > >>
> > >> Now I'm very happy that I managed to recruit Reinhard to help with
> > >> releases, but our two person release team is still understaffed.
> > >> On top of that 0.6 is considerably more work than 0.5 was.
> > >
> > > Id like to hear reinhards oppinon on this thread
> >
> > Thanks for your interest.
> >
> > Because of the vast amount of packages that distro maintainers like me
> > have to consider here, I have to set a synchronization point for the
> > version of FFmpeg all packages have to work with against. For the next
> > version of Debian, this will be FFmpeg 0.5, and currently I know that
> > all of the packages above work with that. Having significantly more
> > potential synchronization points will just lead to upstreams requiring a
> > newer version of FFmpeg that has high potential to break other otherwise
> > unrelated packages.
> >
> >
> > >> I don't have enough time to make even 3-monthly releases...
> > >
> > > Understood
> > >
> > > Reinhard, do you have the time for this or should i try to find someone
> > > else? I probably could do it myself but you did it pretty well and i
> dont
> > > think, given my disinterrest in releases, that i would achive the same
> > > quality.
> >
> > In principle, I think I could also do faster releases. But let me
> > express my understanding of the requirements.  OTOH, we have developers,
> > that want to develop and experiment always with the latest and greatest.
> > In order to get "the crack of the day", svn and compiling statically is
> > obviously the and most convenient method here. Every FFmpeg developer
> > fits in this class. For this group, daily releases (== "svn checkouts"?)
> > are probably the best choice.
> >
> > Then there is the group of developer that works on application packages
> > (think mplayer, xine, vlc, etc.).  They would probably benefit from
> > faster releases than we currently have, maybe 3-6 monthly releases I'd
> > guess.
> >
> > The last group are system integrators and distributors that need to get
> > a large amount of packages working together. These are almost always
> > very busy at very boring tasks like figuring out in what weird and
> > broken ways application packages misuse ffmpeg's APIs and try to fix
> > them. For them I'd guess 12-18 months releases would suit best.
> >
> >
> > As compromise I could therefore indeed imagine to do 3 monthly releases,
> > but *in addition* declare some of those releases as special, long-term
> > releases that are targeted for distros and system integrators.  These
> > would then probably come with a more elaborated changelog and APIChanges
> > diff, and probably other things that simplifies the work of system
> > integrators.
>
> i disagree with your view.
> libav* should like any other lib ensure compatibility of its ABI/API
> unless the major version /soname is bumped
> and applications should only use the public API/ABI
> if libav* breaks its ABI, we messed up and we should be beaten with a stick
> if an application uses non public ABI that application should be fixed
> upstream.
> distros should use the latest releases that are considered stable by
> the respective upstream.
>
> IMO the idea of debian stable that refuses to update its software is not
> fit for todays quickly advancing world nor was it in the past.
> And i have no interrest at all to support it because it actively harms
> users, by giveing them outdated, exploitable and buggy software.
> (yes you do outstanding work with 0.5 and 0.6 but thats just now and you,
>  before
>  this there where known exploits for a very long time and there are many
>  packages in debian where security issues that could be fixed with a
>  single line chnage lay years with no action.)
> And iam speaking as someone who used debian since more than 10 years on
> various computers. Dont ask me on how many of my computers the debian
> "stable" kernel worked thelast time i tried. Dont ask me how many
> packages ive run into in stable that simply dont work at all.
> And yes i should have reported it all but almost every problem i had
> disappeared by upgrading to upstream
> And one of the few i reported led to the package being removed instead
> of the single line change that would have fixed it.
>
> IMO what actually exists is not thousands of packages that work fine but
> are somewhat outdated. What exist are hundreads of packages that have
> been patched to compile without ever being tested or working at all.
> so yeah you have 61 packages to compile with ffmpeg 0.5 but how many
> are actually doing what the user wants in actual day use?
> I claim the users would be better out with ffmpeg 0.6 and maybe 3 of
> these packages less. Projects that use internal ABI so that they
> continously break likely mess up in many other ways too and its
> something that should be brought up on the upstream MLs and fixed
> there
>
>
The problem isn't just applications using internal ABI. Regressions are also
a major concern. There are a large number of fairly high profile formats
(like mp3, AAC, vorbis, theora, wmv3) that are covered by neither the
regression make target nor FATE.