[FFmpeg-devel] [PATCH 1/2] doc/developer: reword some of the policies
Michael Niedermayer
michael at niedermayer.cc
Sun Oct 2 03:42:34 EEST 2016
On Sun, Oct 02, 2016 at 12:01:46AM +0100, Josh de Kock wrote:
> Removed allowing for commiting disabled, unfinished code. Code
> should always try be in a working state.
This is sometimes not exactly possible due to the lack of samples
to test code, or lack of access to specific devices to test things
its still usefull to have the best effort
implementation available directly in the source but disabled by
default
possibly with a request for a sample if that is what is missing
Its also useful for collaboration to have work in progres available
in the main master "development" git repository
We also have flags for experimental code like
AV_CODEC_CAP_EXPERIMENTAL
FF_COMPLIANCE_EXPERIMENTAL
...
> Explicitly state that FATE should pass, and code should work
> for all reviewers who tested.
>
> Signed-off-by: Josh de Kock <josh at itanimul.li>
> ---
> doc/developer.texi | 89 ++++++++++++++++++++++++++----------------------------
> 1 file changed, 42 insertions(+), 47 deletions(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 4d3a7ae..d4344ff 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -247,7 +247,7 @@ For Emacs, add these roughly equivalent lines to your @file{.emacs.d/init.el}:
> @section Development Policy
>
> @enumerate
> - at item
> + at item Licenses for patches must be compatible with FFmpeg.
> Contributions should be licensed under the
> @uref{http://www.gnu.org/licenses/lgpl-2.1.html, LGPL 2.1},
> including an "or any later version" clause, or, if you prefer
> @@ -260,15 +260,13 @@ preferred.
> If you add a new file, give it a proper license header. Do not copy and
> paste it from a random place, use an existing file as template.
>
> - at item
> -You must not commit code which breaks FFmpeg! (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.
> + at item You must not commit code which breaks FFmpeg!
> +This means unfinished code which is enabled and breaks compilation,
> +compiles but does not work or breaks the regression tests). Always
> +check the mailing list for any reviewers with issues and test FATE
> +before you push.
>
> - at item
> + at item Keep the main commit message short with an extended description below.
> The commit message should have a short first line in the form of
> a @samp{topic: short description} as a header, separated by a newline
> from the body consisting of an explanation of why the change is necessary.
> @@ -276,30 +274,29 @@ If the commit fixes a known bug on the bug tracker, the commit message
> should include its bug ID. Referring to the issue on the bug tracker does
> not exempt you from writing an excerpt of the bug in the commit message.
>
> - at 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.
> -
> - at item
> -Do not commit unrelated changes together, split them into self-contained
> -pieces. Also do not forget that if part B depends on part A, but A does not
> -depend on B, then A can and should be committed first and separate from B.
> -Keeping changes well split into self-contained parts makes reviewing and
> -understanding them on the commit log mailing list easier. This also helps
> -in case of debugging later on.
> + at item Testing must be adequate but not is not required to be excessive.
Thats not a english sentance
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161002/8f25ace7/attachment.sig>
More information about the ffmpeg-devel
mailing list