On Thu, 2 Mar 2017 12:44:57 +0100 Michael Niedermayer <mich...@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 <ceffm...@gmail.com> wrote: > > > > > 2017-03-01 12:36 GMT+01:00 wm4 <nfx...@googlemail.com>: > > > > On Wed, 1 Mar 2017 12:20:10 +0100 > > > > Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > > > > > > >> 2017-02-25 15:59 GMT+01:00 wm4 <nfx...@googlemail.com>: > > > >> > I'm documenting existing practice. > > > >> > > > >> > -@subheading Always wait long enough before pushing changes > > > >> > +@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
