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

wm4 nfxjfg at googlemail.com
Thu Mar 2 19:30:21 EET 2017


On Thu, 2 Mar 2017 17:34:11 +0100
Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:

> 2017-03-01 13:31 GMT+01:00 wm4 <nfxjfg at googlemail.com>:
> > 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?  
> 
> 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.
> >> >  
> >> >> > + at 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 at 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.


More information about the ffmpeg-devel mailing list