[FFmpeg-devel] [PATCH] doc: clarify development rules

Michael Niedermayer michael at niedermayer.cc
Thu Mar 2 13:44:57 EET 2017


On Wed, Mar 01, 2017 at 01:31:02PM +0100, wm4 wrote:
> On Wed, 1 Mar 2017 13:06:29 +0100
> Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> 
> > 2017-03-01 12:36 GMT+01:00 wm4 <nfxjfg at googlemail.com>:
> > > On Wed, 1 Mar 2017 12:20:10 +0100
> > > Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> > >  
> > >> 2017-02-25 15:59 GMT+01:00 wm4 <nfxjfg at googlemail.com>:  
> > >> > I'm documenting existing practice.  
> > >>  
> > >> > - at subheading Always wait long enough before pushing changes
> > >> > + at subheading Always wait long enough before pushing changes
> > >> > to code actively maintained by others  
> > >>
> > >> I suspect this is missing an exception for security issues if you want to
> > >> document the actual practice.  
> > >
> > > I can add to the end of the subheading:
> > >
> > >   Critical security issues are an exception. These can be pushed after
> > >   the patch has been for 24 hours on the mailing list and the maintainer
> > >   didn't respond yet, and nobody has rejected the patch. In addition,
> > >   if another committer has approved the patch and acknowledged the
> > >   urgency of the fix, the patch can be pushed immediately.  
> > 
> > I will most likely not fix a (real) security issue, but above seems quite
> > unpractical to me (and unreasonable for real security issues).
> 
> How is that impractical? What do you suggest?
> 
> I certainly hope you're not suggesting that security-sensitive changes
> to code the patch author does not maintain can be pushed without reviews
> at all.

I dont know what carl meant exactly but as one doing many of the fixes
there are a few words i should say

Posting patches is only usefull if more issues are found in the
posted patch as a result of it being posted than if it wasnt posted.
It seems few issues are found in patches in this category when posted.
Posting patches interrupts the development cycle, normally i would
debug an issue, write a fix, test and review the fix and if iam
unsure and theres someone who knows the code better post a patch
(either privatly or publically as the case demands)
otherwise push and backport and then the next issue.
The cases where no patch is posted, the pushing and local backport
happens immediately, but if i post a patch and wait 24h by the time i
backport it to the releases its been a longer time and there have been
many other issues in the meantime, that makes backports harder,
less common and lower quality. Thats what iam seeing in the last
days not a imagined issue.
Also i think iam more sloppy with self reviewing my code when i post
a patch

Also adding a unconditional 24h delay for changes makes the whole
process more work. The time i can spend on FFmpeg is limited, if i
send a patch in every case and not just in cases were theres an
active maitainer who wants and does review things before being
pushed. Then the result is some other things arent done anymore simply
due to lack of time, If you want a concrete example you can look at
my gnu/kfreebsd fate client, it stoped working days ago and i noticed
but simply didnt had the time to look into it, previously i always
looked into such things quickly when i noticed.


And posting about (serious) security issues in public before fixing
them adds time for anyone wanting to exploit it

posting patches and waiting has a cost and we should only pay that
when we get more value back.

On a slightly differnt topic, accusing other fellow developers also
has a cost, not just everyones time but also at least for me, the
will and interrest to work in this environment

and now ill try to stay out of this (rather timeconsuming disscussion)
like i did before, just wanted to send one mail as the discussion was
about security and related patches which i work on alot ...

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20170302/23baae27/attachment.sig>


More information about the ffmpeg-devel mailing list