On Sat, Apr 09, 2011 at 11:58:35PM +0200, Luca Barbato wrote: > developer.texi is quite outdated, I started fixing some details and ended > up rewriting a large part, this rfc patch is just for discussion. > > --- > doc/developer.texi | 201 ++++++++++++++++++++------------------------------- > 1 files changed, 79 insertions(+), 122 deletions(-) > > diff --git a/doc/developer.texi b/doc/developer.texi > index ec196d7..d7996f4 100644 > --- a/doc/developer.texi > +++ b/doc/developer.texi > @@ -23,16 +23,16 @@ audio or video streams. > > @end itemize > > -@section Integrating libavcodec or libavformat in your program > +@section Integrating libav in your program > > -You can integrate all the source code of the libraries to link them > -statically to avoid any version problem. All you need is to provide a > -'config.mak' and a 'config.h' in the parent directory. See the defines > -generated by ./configure to understand what is needed. > +Shared libraries should be used whenever is possible in order to reduce > +the effort distributors have to pour to support programs and to ensure > +only the public api is used. > > You can use libavcodec or libavformat in your commercial program, but
Libav
> -@emph{any patch you make must be published}. The best way to proceed is
> -to send your patches to the Libav mailing list.
> +you must abide to the license (LGPL or GPL depending on the specific features
> +used). Any modification to the source code can be suggested for inclusion.
> +The best way to proceed is to send your patches to the Libav mailing list.
It should link to the compliance checklist in
http://libav.org/legal.html
>
> @anchor{Coding Rules}
> @section Coding Rules
> @@ -129,17 +129,32 @@ should also be avoided if they don't make the code
> easier to understand.
> an "or any later version" clause is also acceptable, but LGPL is
> preferred.
> @item
> - You must not commit code which breaks Libav! (Meaning unfinished but
> - enabled code which breaks compilation or compiles but does not work or
> - breaks the regression tests)
> - You can commit unfinished stuff (for testing etc), but it must be disabled
> - (#ifdef etc) by default so it does not interfere with other developers'
> - work.
> + All the patches MUST be reviewed in the mailing list before they are
> + committed.
> @item
> - You do not have to over-test things. If it works for you, and you think it
> - should work for others, then commit. If your code has problems
> - (portability, triggers compiler bugs, unusual environment etc) they will
> be
> - reported and eventually fixed.
> + The Libav coding style should remain consistent. Changes to
> + conform will be suggested during the review or implemented on commit.
> +@item
> + Patches should be generated using @code{git format-patch} or directly sent
> + using @code{git send-email}.
> + Please make sure you give the proper credit setting the correct author in
credit by setting
> + the commit.
> +@item
> + The commit message Should have a short single line in the form of
s/single/first/
> + @samp{topic: short description} with few lines explaining the reason of
> the
few following lines?
--
Anton Khirnov
signature.asc
Description: Digital signature
_______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
