[FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Compn]

On Mon, 27 Nov 2017 23:46:30 -0800, Jim DeLaHunt
<from.ffmpeg-dev at jdlh.com> wrote:

> On 2017-11-27 15:00, Carl Eugen Hoyos wrote:
> > 2017-11-26 22:44 GMT+01:00 Jim DeLaHunt <from.ffmpeg-dev at jdlh.com>:
> >> So, how realistic is this concern about non-subscribers sending 
> >> patches to
> >> ffmpeg-devel?  Does it actually happen?
> > This is very realistic afair.
> OK, and Lou Logan corroborates Carl Eugen:
> On 2017-11-27 15:19, Lou Logan wrote:
> > A very rough guess is that there are usually at least several
> > patches from unsubscribed users a week (in fact there was one in the
> > queue minutes ago).
> 
> So I accept that welcoming non-subscribers sending patches to 
> ffmpeg-devel is a real concern. I was skeptical, but I was wrong.

Let me also echo Lou and Carl's concerns. I am one of the other ML
admins/mods and just 2 days ago approved submission to -devel a patch
that was stuck in the mod queue because the author was not subscribed.
i also auto-approved all future mails from that author.

Patches without subscription happens often, couple times per month? The
list traffic is immense (thousands of patches and discussions per
month) and most people just want to drop a patch and run. Most smaller
quick clear error fixing patches are accepted i would say, so this
situation works.

of course we are always looking for better practices, so we also have
patchwork installed:

https://patchwork.ffmpeg.org/project/ffmpeg/list/

unfortunately , we have also seen many distros and projects maintain
their own ffmpeg patches, sometimes for years. never submitting them
back to us. we are trying to improve this situation in any way that we
can.

i'm not trying to dogpile on you, just explaining the situation.

> Also, someone once observed that common sense is not very common. :-)

sure, but please remember the DOCS are already quite verbose, and
brevity is the soul of wit. so if you can say more with less verbiage
that would be great.

> -----
> It is important to be subscribed to the
> @uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel, ffmpeg-devel}
> mailing list, because any non-trivial patch you contribute must be sent 
> there
> and reviewed by other developers. They may have comments about your
> contribution. We expect you see those comments, and to improve your 
> contribution
> if requested. (N.B. Experienced committers may sometimes skip review for 
> trivial fixes.)
> Also, this list is where bug fixes and ffmpeg improvements from other 
> developers
> are discussed. That may be helpful information as you write your 
> contribution. Finally, by being a list
> subscriber your contribution will be posted immediately to the list,
> without the moderation hold which messages from non-subscribers experience.
> 
> However, it is more important to the project that we receive your
> patch than that you be subscribed to the ffmpeg-devel list. If you
> have a patch, and don't want to subscribe and discuss the patch,
> then please do send it to the list.
> -----

i think your additions are well meaning, but the above is repetitive and
can be made smaller. e.g. you use the words contribution, comments etc
multiple times. i could attempt a rephrasing if you want? i would have
done so in this mail but i am in a rush atm.

Also please note that most ffmpeg developers and patch authors are from
around the world , and english may not be their native language.


>I am trying to contribute patches to fix the most severe, easiest to fix bugs in the docs.

no problem. thanks for contributing.

> I find it interesting that bug fixes and enhancements to the source code 
> of ffmpeg are approved so much more easily than this patch's bug fixes 
> and enhancements to the text of ffmpeg.org. This is not a smooth 
> documentation process.

haha! well let me please explain to you what situation you have gotten
yourself stuck into! :)

the development docs that you want to patch are actually the ffmpeg
project's written rules and policy that governs the whole shebang.

so these are the rules that all devs must agree to within the project.
sure, we bicker about the rules and not everyone follows every rule,
and we have many unwritten rules that we also abide by. which also
causes great strife sometimes when someone thinks a rule is official or
not... look i didnt say it was a good system, it is what we have
evolved into over the years.

the point is that changes to this specific part of the documentation
affects all devs, not just new contributors. so we are more interested
to changes of this document. especially large changes all in one patch.

what your v1 patch has unintentionally done is to change our long
standing ffmpeg policy about patch submission and review. i know this
was not your intention, but you have picked one of the core parts of the
project to modify on your first attempt. :)

hope this clears things up. feel free to ask me questions off list, or
we can be found on irc.freenode.net #ffmpeg-devel as well for real
time chat.

tl;dr my suggestions:
1. split docs patch
2. less words, rephrase for brevity
3. welcome to open source team collaboration :)

-compn