[FFmpeg-devel] [RFC] Releases

[Reinhard Tartler]

On Mo, Mai 31, 2010 at 17:41:06 (CEST), Michael Niedermayer 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".

this has slightly changed in the very recent times by upstaffing the
"stable release team".  nowadays even minor, non-security fixes are
being accepted for point releases.

moreover, for volatile software there is volatile.debian.org, and if
everything else fails, there is backports.org (soon to be made
backports.debian.org)


>> 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.

That's unsurprising, we had this discussion several times now and we had
never an agreement.

> 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.

which doesn't work in practice, because

> IMO the idea of debian stable that refuses to update its software

And your idea that this...

> is not fit for todays quickly advancing world nor was it in the past.

This does not match the opinion of the folks that actually run and use
Debian releases. If you want something faster paced, there are a lot of
other, less successful distros that actually do implement what you
propose.

But is this a valid reason to penalize distros that do not share your
view? I think not. It's a different philosophy how to run a distro. And
that's OK in my POV.

> And i have no interrest at all to support it because it actively harms
> users, by giveing them outdated, exploitable and buggy software.

Free software is about choice. Most users that choose debian do so
because they do agree on how debian does releases. Otherwise they would
choose a distro that suits them more, no?

> (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.)

Well, then let's be happy that this is not the case anymore and continue
to keep that up!

> 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.

I'm sorry about your frustration with your experience with Debian. I
don't claim debian's approach to releases to be perfect, but for my
personal and work-job uses which includes both desktops and servers, it
works great. And according to distrowatch.com and similar sites, I'm not
alone with that opinion.

This doesn't mean that we cannot do better. The last thing you've said
in your mail leads me to an proposal:

> 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

in a perfect world without deadlines, disagreements and all flames, this
would work.  Since I do not live in utopia land, we could do something
that should almost match your idea:

Let's do the fast paced releases strictly time based. Based on that,
I'll provide packaging so that FFmpeg can provide always uptodate Debian
packages that replace the system FFmpeg. (Actually, that's already on my
todolist, but anyways). These packages get uploaded to Debian
experimental ASAP, and for ubuntu to a PPA.

Additionally, we can provide daily builds for in form of packages for
stable distro releases out of svn.  Ideally we can build them on fate
machines and publish them on ffmpeg.org. This way users can easily test
and use really uptodate packages.

And by this, we can see much more quickly how what application package
get broken by changes in FFmpeg.


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