[FFmpeg-devel] [PATCH] doc: clarify development rules
nfxjfg at googlemail.com
Thu Mar 2 13:50:31 EET 2017
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 ...
It seems you didn't read what I wrote. If another committer says ok to
the patch (even on IRC), it would be ok.
More information about the ffmpeg-devel