2017-03-01 13:31 GMT+01:00 wm4 <nfx...@googlemail.com>: > 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?
Posting security issues and wait for comments does not seem like a useful approach. > 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 believe this is the established practice that you want to document iiuc. >> > Maybe a bit long, but should cover all bases. >> > >> >> > +@subheading Pushing patches without sending them to the mailing list >> >> > +If you're the maintainer of a file, or the file is not actively >> >> > maintained by >> >> > +anyone, or the file is not covered by the MAINTAINERS file, you can >> >> > just push >> >> > +them without asking for permission, and without sending them to >> >> > ffmpeg-devel. >> >> > +This right only applies to developers with git push access, of course. >> >> >> >> > +A maintainer is considered not active if he hasn't posted a mail to >> >> > ffmpeg-devel >> >> > +for longer than 6 months, and hasn't pushed a patch in that time >> >> > period himself. >> >> >> >> Unfortunately, there are maintainers who are happy to review patches >> >> sent to improve their code but the files were not touched for more than >> >> six months so they did not seem active for more than six months. >> > >> > So what is a reasonable method of determining whether a maintainer >> > is reachable? >> >> I fear there is no strict definition, patches can always be reverted though >> if a maintainer requests that. >> >> I am just (slightly) against writing "after six months, you are no more a >> maintainer". > > That's not what I wrote. But this is how the change of text can be interpreted. > It merely means that if you have showed no sign of activity after 6 > months, the timeout can be skipped. As said, this is not a sufficient sign for non-maintenance. >> > The worst part is that not even "active" maintainers always respond, >> > even if you go a timeout. >> >> Then you push after the timeout (if no delay was requested). > > michaelni didn't wait when pushing his vp56.c patches (didn't even send > them to the mailing list), even though it was a mid-sized (i.e. not > small) change. The patch did not change API (which would require the patch sent to the mailing list) and vp56.c is not actively maintained, so I don't understand what you are trying to say. > The maintainer of vp56.c is still reachable by mail, but > hasn't posted or contributed anything to ffmpeg in 3.5 years. michaelni > didn't wait for the timeout, which does not match with what you seem to > demand. No, you misunderstand: I am just pointing out that a pure time-out is not sufficient to decide on maintenance. > Please explain what the rules of this project are. As you know, I disagree with several of the rules, and I have said so. You have - afaict - agreed to them and I still feel that you prefer not to obey. I have no idea what I can explain to you. Generally, I honestly don't understand what you are trying to achieve with your emails. Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
