On Sun, Oct 02, 2016 at 11:16:49PM +0100, Josh de Kock wrote: > > > On 02/10/2016 22:47, Michael Niedermayer wrote: > >On Sun, Oct 02, 2016 at 01:51:41AM +0100, Josh de Kock wrote: > >>Explicitly state that FATE should pass, and code should work > >>for all reviewers who tested. [...] > >>-@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. > >>+@item Testing must be adequate but not excessive. > >>+If it works for you, others, and passes FATE then it should be OK to commit > >>+it, provided it fits the other committing criteria. You should not worry > >>about > >>+over-testing things. If your code has problems (portability, triggers > >>+compiler bugs, unusual environment etc) they will be reported and > >>eventually > >>+fixed. > >>+ > >>+@item Do not commit unrelated changes together. > >>+They should be 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. > >> Also if you have doubts about splitting or not splitting, do not hesitate > >> to > >> ask/discuss it on the developer mailing list. > >> > > > >>-@item > >>+@item API/ABI breakages and changes should be discussed before they are > >>made. > > > >I dont think this should list "breakages" > >"breakages" are a subset of "changes" > >and except in exteemly rare cases "breakages" should not happen > >intentionally > > > > That makes sense, I'll push a couple days with `s/breakages and //` > if there are no further comments.
not sure this fits in the patchset but maybe "deprecation" should be added as deprecation implies future change. Such change of course needs to be discussed. Discussing it at the time of deprecation is better than after. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert"
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
