[FFmpeg-cvslog] r23904 - in trunk: cmdutils.h libavcodec/aac_parser.h libavcodec/ac3.c libavcodec/ac3.h libavcodec/ac3_parser.h libavcodec/ac3tab.c libavcodec/allcodecs.c libavcodec/alsdec.c libavcodec/avcodec.h l...

Diego Biurrun diego
Fri Jul 2 15:26:29 CEST 2010


On Thu, Jul 01, 2010 at 05:44:22PM +0200, Michael Niedermayer wrote:
> On Thu, Jul 01, 2010 at 04:16:49PM +0200, Diego Biurrun wrote:
> > On Thu, Jul 01, 2010 at 12:34:48AM +0200, Stefano Sabatini wrote:
> > > On date Wednesday 2010-06-30 22:00:01 +0200, Diego Biurrun wrote:
> > > > On Wed, Jun 30, 2010 at 09:08:04PM +0200, Vitor Sessak wrote:
> > > > > On 06/30/2010 08:55 PM, Alex Converse wrote:
> > > > >> 2010/6/30 M?ns Rullg?rd<mans at mansr.com>:
> > > > >>> Michael Niedermayer<michaelni at gmx.at>  writes:
> > > > >>>
> > > > >>>> On Wed, Jun 30, 2010 at 06:46:05PM +0100, M?ns Rullg?rd wrote:
> > > > >>>>> Michael Niedermayer<michaelni at gmx.at>  writes:
> > > > >>>>>
> > > > >>>>>> On Wed, Jun 30, 2010 at 05:38:06PM +0200, mru wrote:
> [...]
> > > >  Would you let Diego dictate rules for
> > > > >>> your asm code?  Didn't think so.  Now please allow the experts in each
> > > > >>> area to do their job.  Your expertise is in writing fast C code, not
> > > > >>> in English grammar.
> > > > >>>
> > > > >>
> > > > >> This is probably the wrong place to weigh in, but as a native English
> > > > >> speaker I agree with M?ns here.
> > > > >
> > > > > As a non-native speaker (we are the majority here, no?), I am strongly  
> > > > > against adding more english-related red-tape for getting code committed.  
> > > > > Really, getting comments that use good wording and have no grammatical  
> > > > > mistakes take time already, having to avoid _correct_ grammar forms is  
> > > > > just silly. I'm all for consistency, but it has a price and here I think  
> > > > > it is not worth it.
> > > > 
> > > > That's why third person should be avoided, too.  It's simpler to write
> > > > in impersonal form.
> > > 
> > > I agree with the purpose of the commit, but the way it has been done,
> > > in open contrast with the rules of this community, is deprecable.
> > 
> > Dunno what you mean by "deprecable".
> > 
> > I'll go on record now that Mans asked me before committing and I told
> > him to go ahead.  A JFDI attitude is sometimes better than endless
> > bikeshedding.  The problem about this particular bikeshed is that it is
> > a revolution of the great unwashed against the experts.
> 
> i politely request that you refrain from personal insults.
> There is no need to call thouse who disagree with you "great unwashed"
> Didnt we had enough flaming already?

s/great unwashed/less skilled/ if you prefer, no personal insult intended

> > FFmpeg is not about democratic decisions. 
> 
> It is. And it always was.

Nope, it is not and never has been, no matter what you claim.

Developers are *not* created equal around here.  Maintainers trump the
commoners and your word has more weight than most others'.  Decisions
usually get made by discussions among experts with the non-experts
remaining silent.  Where no consensus can be reached seniority and
standing are the decisive factors.

The last time I remember us voting about something was whether or not
warnings should be fixed.  In the preceding discussion you were clearly
outnumbered already, it took a 10-1 (or so, I don't remember exact
numbers) majority during the vote to sway you.

If this Doxygen issue was a democratic decision then it has already been
conveniently settled and you should accept the result.  There was Mans,
Alex and me in favor with you against and Stefano neutral.  You can count
heads or you can weigh competence, either way, the decision is the same.

Note that I have no problem with the FFmpeg way of decision-making and
I accept you have more seniority and expertise in most things that
concern this project.  But wrong characterizations of the decision-making
process I will not let stand unanswered.

Diego



More information about the ffmpeg-cvslog mailing list