[FFmpeg-devel] [PATCH] PB-frames support for i263

[Michael Niedermayer]

On Sat, Feb 21, 2009 at 06:51:05PM +0100, Diego Biurrun wrote:
> On Sat, Feb 21, 2009 at 11:41:37AM +0100, Michael Niedermayer wrote:
> > 
> > code that is under if(not true in current working cases) is not going to break
> > the release and thus there is
> > no sense to delay it also code that handles cases that just returned -1
> > before is also not going to break the release.
> > Compared to this many bug fixes which are needed have a very high potential
> > to break the release.
> 
> I never said such code should not be committed, I just said that people
> should be extra confident that they will not cause regressions.
> 
> That said, even the seemingly harmless openjpeg wrapper support had
> subtle bugs regarding the wrong #include path...

i think many bug fixes have a much higher chance of causing regressions
than adding seperate and new features.
for example a commit to ffplay.c that i approved to fix some "memleak" EOF
issue likely caused a regression with decoding of the last frames.


> 
> > also iam considering to forbid any future freeze of head if development is
> > stoped like that. If the release manager considers a freeze needed that can
> > be done after forking and limited to the fork.
> > Its enough that development of core parts is stoped, stopping addition of
> > new features that cannot break existing feaures is just lame.
> 
> No development is stopped.  It is just being refocussed.  We have indeed
> seen many bug fixes during the past two weeks, more than usual.  And

we have seen more activity in general in the last weeks, more than usual,
i dont think the percentage of bug fixes really is higher though but then
i didnt make a statistic its just my feeling and few "fixes issue123" in
commits ...


> people do appear to be exceptionally active.  This is a good thing that
> benefits FFmpeg as a whole.
> 
> Kostya is still working on other things, it's not a setback if he
> commits the new table generator in a week.  

> Two weeks of freeze after
> more than 200 weeks of open trunk will not hurt anybody or cause big
> amounts of delay.

this may be what you hope or guess


> 
> Also, as I said, let's collect some experience first and argue about
> results and possible improvements after the fact.  Right now it's just a
> distraction.

so is your attempt at changing of the schedule of lifting the freeze on HEAD.
If you ask me and others to stay silent then first you should heed your own
advise, and accept the original schedule and we can then after the release,
discuss it all.

You are the release manager and you can release when and what you want
and you can fork and keep that fork frozen as you see fit but you cannot
change the schedule of the freeze on HEAD without the agreement of the
ffmpeg developers.

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/20090221/0bd36ab7/attachment.pgp>