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

[Stefano Sabatini]

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...

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.

Regards.
-- 
FFmpeg = Furious Faithless Mournful Philosofic Eccentric Ghost