[FFmpeg-cvslog] r9307 - in trunk/libavcodec: dsputil.c mpegvideo.c

[Michael Niedermayer]

Hi

On Fri, Jun 15, 2007 at 07:33:41PM +0100, M?ns Rullg?rd wrote:
> Aurelien Jacobs <aurel at gnuage.org> writes:
> 
> > On Fri, 15 Jun 2007 14:52:35 +0200
> > Michael Niedermayer <michaelni at gmx.at> wrote:
> >
> >> Hi
> >> 
> >> On Fri, Jun 15, 2007 at 01:22:09PM +0200, Aurelien Jacobs wrote:
> >> > On Fri, 15 Jun 2007 12:56:10 +0200
> >> > Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> >> > 
> >> > > Hello,
> >> > > On Fri, Jun 15, 2007 at 10:17:09AM +0200, Diego Biurrun wrote:
> >> > > > On Fri, Jun 15, 2007 at 10:06:55AM +0200, Reimar Doeffinger wrote:
> >> > > > > On Thu, Jun 14, 2007 at 10:44:41AM +0200, diego wrote:
> >> > > > > > 
> >> > > > > > Log:
> >> > > > > > Simplify init preprocessor statements.
> >> > > > > > patch by Albert Lee, trisk+xine acm.jhu edu
> >> > > > > 
> >> > > > > As discussed this has a sideeffect and IMO also removes a feature (using
> >> > > > > accelerated functions from different "areas"), so I'd request this to be
> >> > > > > reverted unless there is a really, really good reason to do it like
> >> > > > > this (and even then the log message is not okay).
> >> > > > 
> >> > > > AFAICT all of these options except for mlib are mutually exclusive,
> >> > > > right?  So the right solution IMO is to take just mlib out of the #if
> >> > > > #elif construction.
> >> > > 
> >> > > I do not know, and what is the advantage that would justify trying to
> >> > > find out? Just to get rid of 12 #endifs? If it bothers you as much,
> >> > > IMO just switch to the "if (ENABLED_*)" construct used elsewhere, then
> >> > > you can even put it all in one line.
> >> > 
> >> > Indeed this would looks much cleaner.
> >> > First attached patch is needed to have ENABLE_* defined for MMX, etc...
> >> > Then second patch cleanup this #ifdef mess.
> >> 
> >> looks ok
> >
> > applied
> 
> Neither myself nor Diego approved this configure change.  That's not
> saying I disagree with it, just that Michael isn't playing by the same
> rules he sets for others.

ive approved the dsputil change, i also thought and think the configure
change is ok and doesnt really need approval ...

and about the same rules ... i just a few hours ago told takis to commit
trivial / non controversal changes without sending patches and i told
others the same ...

then you should at least flame aurelian too as he approved a change to
a file you maintain in 
[FFmpeg-devel] [PATCH] Make golomb.c compilation optional

there you said:
-------
>> Patch ok.
>
> Is it okay to apply, or should I wait for the ones specified as
> maintainers for this file to confirm it (those being Diego and M?ns)?

Go ahead and apply.
-------

and iam sure i could find more if i spend another 2 minutes looking at random
mails from you, have you never approved a trivial patch to code someone else
maintains?

we are all busy and sending patches for everything and waiting for approval
for every changed line would IMHO not really help the project
if theres a bug in my code then people should just fix it if they are sure
there fix is correct, if not they should send a patch
diego also just commted spelling fixes instead of going for patch sending and
approval, i think diego did the correct thing

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- 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-cvslog/attachments/20070615/454f3ed9/attachment.pgp>