[FFmpeg-devel] [PATCH/RFC]Change development policy

[Michael Niedermayer]

On Mon, Oct 04, 2010 at 11:45:28PM +0200, Stefano Sabatini wrote:
> On date Monday 2010-10-04 23:28:01 +0200, Benjamin Larsson encoded:
> > On 10/04/2010 01:04 PM, Michael Niedermayer wrote:
> > > On Mon, Oct 04, 2010 at 11:22:51AM +0200, Carl Eugen Hoyos wrote:
> > >> Hi!
> > >>
> > >> I believe this was originally suggested by Reimar, and since supported by 
> > >> several developers.
> > >>
> > >> Since this may be controversial, please comment in any case and suggest 
> > >> wording improvements, flames (including whose idea it was) are less welcome.
> > >>
> > >> I will consider applying if I receive no comments at all, Carl Eugen
> > > 
> > >>  developer.texi |    3 +++
> > >>  1 file changed, 3 insertions(+)
> > >> 290cbac2de815e5b43f4e3fcc065bdc9b13648e4  patchAPI.diff
> > >> Index: doc/developer.texi
> > >> ===================================================================
> > >> --- doc/developer.texi	(revision 25330)
> > >> +++ doc/developer.texi	(working copy)
> > >> @@ -155,6 +155,9 @@
> > >>  
> > >>     Note: Redundant code can be removed.
> > >>  @item
> > >> +   Do not apply patches that change public API without discussing them
> > >> +   on the mailing list first.
> > >> + at item
> > > 
> > > I suggest:
> > > diff --git a/doc/developer.texi b/doc/developer.texi
> > > index e362eec..9c43123 100644
> > > --- a/doc/developer.texi
> > > +++ b/doc/developer.texi
> > > @@ -149,7 +149,8 @@ should also be avoided if they don't make the code easier to understand.
> > >     Also if you have doubts about splitting or not splitting, do not hesitate to
> > >     ask/discuss it on the developer mailing list.
> > >  @item
> > > -   Do not change behavior of the program (renaming options etc) without
> > > +   Do not change behavior of the program (renaming options,
> > > +   changing public API or ABI, etc) without
> > >     first discussing it on the ffmpeg-devel mailing list. Do not remove
> > >     functionality from the code. Just improve!
> > > 
> > 
> > Both ok but I prefer this one.
> 
> I prefer the second variant but in the present form is not accurate.
> 
> API change doesn't imply change in the programs behavior, so I
> suggest:
> 
> Do not change behavior of the programs (renaming options, adding
> options, changing the use of pre-existent options, etc) or the public
> API or ABI without...

that are a lot of unrelated changes.


> 
> Also I'd like a note along the lines:
> 
> Huge or non trivial changes or new element additions should be posted
> for review as well.

huge things should be split or if they are already split and still are
huge then they will touch many files (like whitespace reformatting)
and this already has to be posted because it pretty much inevitably will
touch code from other maintainers.

also your suggestions sound alot like "send patches for everything".
and this is drifting off topic, the policy is not a text to be rewritten
radically after having had 2 sixpacks of beers like you seem to try here.
But instead each individual change should be justified and discussed

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101005/e4673cde/attachment.pgp>