[Ffmpeg-devel] Re: Creating releases

[Axel Thimm]

On Sat, Apr 14, 2007 at 01:48:15PM +0100, M?ns Rullg?rd wrote:
> Axel Thimm <Axel.Thimm at ATrpms.net> writes:
> 
> > Hi,
> >
> > I know that ffmpeg prefers users to run the latest snapshots. But that
> > doesn't work so well for 3rd party projects (e.g. ffmpeg consumers)
> > and also not for packagers of various distributions.
> >
> > I'm packaging ffmpeg for various Red Hat/Fedora distros and am talking
> > with several other packagers for the same distros on how to get our
> > bits together. Turns out that everyone has a different snapshot where
> > different features/bugs exist. Some have backported selected svn
> > fixes, or have patched up the sources themselves. I think (frequent)
> > releases would help out a lot.
> >
> > I would volunteer to help creating formal releases, so that the ffmpeg
> > development doesn't get slowed down by additional workload. Probably
> > most of the release process could be automated enough to have often
> > enough releases to track the fast development pace of ffmpeg.
> >
> > The choice when to cut a release would have to come from the
> > development team/head, though.
> >
> > What do you think?
> 
> Many projects use an iterative development model where the code is
> chopped into tiny, tiny pieces, and then weeks/months/years are spent
> piecing them back together to form a "release", after which the
> process is repeated again.  In these projects, snapshots between
> releases are very unstable, and often do not even compile.
> 
> FFmpeg does not follow this model.  Our aim is that head of svn should
> always be stable, and to a large extent this is true.  Serious bugs
> usually get fixed rather quickly.  Less serious bugs are equally
> likely to be present in any revision.

That's nice to hear, although I don't believ in bug-free software ;)
But that means that the developers' workload in the release game is
even easier, they can just ping whenever they want, but they will
probably still have preferences of when a release is due to have users
test new features.

> The problem with releases is that users will tend to use (at best) the
> latest release version, and will report bugs against this.  Many of
> these bugs will have been already fixed, and thus investigating these
> reports is largely a waste of developer time.

Stop, I thought you said ffmpeg was almost a bug-free project, why is
this now any issue? Just kidding.

Of course you will get users scattered along releases and snapshots,
but that's the situation today anyway. Most users use some packaged
ffmpeg or a private snapshot of another project that embedded ffmpeg.

By doing your own releases you have control over which parts the users
will get scattered. And by persuading downstream projects to use
releases instead of their own private ffmpeg copy you get well known
points of references.

> If you wish to make releases, nobody will stop you.  However, we would
> ask of you to very clearly request bug reports to be sent to you, and
> that you check the reports against the development head, forwarding
> any bugs that are still unfixed to us.  Of course you would also
> filter out duplicates.

No, I'm not going to fork ffmpeg, becasue that's what the suggestion
aims at. I'm just offereing to help in producing releases. If
development would agree that releases are a bad thing and won't be
bothered, then there will be none.

> To summarize, you are free to make whatever releases you wish, but you
> will be on your own.

Well, not really constructive and not different from the current
situation where everyone and his cat has his very own private ffmpeg
cut.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070414/c6138a49/attachment.pgp>