On Thu, 2 Mar 2017 17:34:11 +0100 Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 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 I give up. Please write a patch to clarify the rules yourself. Otherwise I'm going to assume that the rules are as fuzzy as they seem to be, and I'll adjust my behavior accordingly. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
