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

[wm4]

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.