[FFmpeg-devel] [PATCH] add multiple inclusion guard note to policy

Michael Niedermayer michaelni
Tue Oct 16 23:34:51 CEST 2007


On Tue, Oct 16, 2007 at 10:15:57AM +0200, Diego Biurrun wrote:
> On Mon, Oct 15, 2007 at 11:58:56AM +0200, Michael Niedermayer wrote:
> > On Mon, Oct 15, 2007 at 11:44:22AM +0200, Michael Niedermayer wrote:
> > > 
> > > On Mon, Oct 15, 2007 at 10:56:41AM +0200, Diego Biurrun wrote:
> > > > On Mon, Oct 15, 2007 at 10:45:36AM +0200, Diego Biurrun wrote:
> > > > > All header files should come with multiple inclusion guards.  Here is a
> > > > > patch for the policy.
> > > > 
> > > > .. I guess I have become the undisputed king of forgotten attachments,
> > > > what a crown to wear ..
> > > > 
> > > > Diego AKA scatterbrain #1
> > > 
> > > iam fine with adding this but i do not think that such rather trivial 
> > > rules belong into the policy
> > > 
> > > rules like, use/keep alphabetical ordering where possible, add multiple
> > > inclusion guards on headers, add proper license headers, update the changelog
> > > and docs for new codecs would fit much better into the coding rules
> > > section where also doxygen comments are mentioned or another section ...
> > 
> > IMHO the policy should only contain important rules for which ignoring them
> > would cause significant problems
> > 
> > not spliting patches/commits makes their review very hard asking the author 
> > to split it might lead to a lot more work compared to him knowing that it
> > should be split from the begin ...
> > 
> > not bumping version numbers could lead to serious API/ABI issues
> > 
> > not updating changelog (for new codecs) seems rather benign
> > 
> > not maintaining alphabetical order is rather irrelevant
> > 
> > forgotton multiple inclusion guards might lead to a bug and 10min time wasted
> > and a 3 line fix, this doesnt sound overly significant
> > 
> > mixing cosmetic and non cosmetic changes would make review on svn log very
> > hard, lead to bugs, security issues and in general worse code
> 
> Then call the rest guidelines or whatever.  Splitting that off would
> however, to quote a certain Mr Niedermayer, belong in a separate patch
> ;-p 

yes absolutely :)


> So I think this should be committed as-is, the split can be done
> later if deemed necessary/desirable.

because there are other things in the policy which shouldnt be there we
first move yet more of them in there before we start considering to move all
the stuff out again ...

why dont you create a guidline section and move that new entry there instead?

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- 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/20071016/ac3adaf5/attachment.pgp>



More information about the ffmpeg-devel mailing list