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

Stefano Sabatini stefano.sabatini-lala
Tue Oct 5 00:42:45 CEST 2010


On date Tuesday 2010-10-05 00:24:31 +0200, Michael Niedermayer encoded:
> 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.

Do not change behavior of the program (renaming options, etc) or
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.
> 
> 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.

Discard this part...
-- 
FFmpeg = Frenzy and Fancy Merciless Programmable Empowered Generator



More information about the ffmpeg-devel mailing list