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

[wm4]

On Thu, 2 Mar 2017 12:44:57 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> 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
> 
> [...]

It seems you didn't read what I wrote. If another committer says ok to
the patch (even on IRC), it would be ok.