[FFmpeg-devel] [PATCH/RFC]Change development policy
Stefano Sabatini
stefano.sabatini-lala
Mon Oct 4 23:45:28 CEST 2010
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
More information about the ffmpeg-devel
mailing list