[FFmpeg-devel] release

[Michael Niedermayer]

On Wed, Jan 28, 2009 at 09:10:54PM -0800, Mike Melanson wrote:
> Jai Menon wrote:
> > Hi,
> > 
> > On Thu, Jan 29, 2009 at 10:05 AM, Mike Melanson <mike at multimedia.cx> wrote:
> >> Diego Biurrun wrote:
> >>> Let's get the two biggest bikeshed topics out of the way right now:
> >>>
> >>> - release date: weekend 2009-02-21/22
> >>> - release name: 0.5
> >>>
> >>> There, progress, it feels so great...
> >> Awesome. No argument here. Does anyone have a reason why we shouldn't go
> >> with 0.5 for a release? If you do... I don't really care. :) Let's go
> >> with 0.5.
> >>
> >> BTW, one more pressing matter: How do we actually go about making the
> >> release?
> > 
> > I have another question to add to this. Is there some sort of "feature
> > freeze" or something?
> > Or do we just create a release branch and continue adding new stuff to
> > svn head (and porting
> > bugfixes to the release branch etc...) ?
> > Maybe somebody who knows about this could give a detailed overview of
> > what makes up the release process.
> 
> That's a good question. I don't think anyone has any major features 
> slated to go in before release. If they do, then we can always kindly 
> ask them to hold the features until after mid-February.

I do not entirely agree with this.
First its changes that arent bugfixes and non trivial and to the core that are
risky not so much just "major features".
libavfilter is a major feature but if its under #ifdef there is no way it
could break the alternative path. Nor could a new codec break existing codecs
and a new codec surely is sometimes a major feature

Besides limiting the freeze to non bugfix+non trivial+core there should be
* a sanely set starttime, it might still be too early, that is we shouldnt
  freeze anything when there is still plenty of time to fix new bugs
* a strict end time, if the release happens 22. feb then the freeze ends
  on 22. feb, if the release does not happen on 22. the freeze still ends
  there. Its completly unacceptable to have a slipping release shedule
  cause development to stop on some parts of ffmpeg for longer than needed

But personally i strongly would prefer if people would forget the
idea of freezing anything at all. Rather just
* fix bugs, 
* try not to break things shortly before the release
* release quickly or dont release.
why?
because you are trying to solve a problem we never had, its just some
hypothetical "it could break ..."
Noone wants to be the one who broke the release this alone should keep
devels much more carefull about what they commit, we shouldnt need a
freeze

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

Thouse who are best at talking, realize last or never when they are wrong.
-------------- 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-devel/attachments/20090129/4fe7194d/attachment.pgp>