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

[Carl Eugen Hoyos]

2017-11-26 22:44 GMT+01:00 Jim DeLaHunt <from.ffmpeg-dev at jdlh.com>:
> On 2017-11-26 03:42, Carl Eugen Hoyos wrote:
>>
>> 2017-11-26 9:31 GMT+01:00 Jim DeLaHunt <from.ffmpeg-dev at jdlh.com>:
>>>
>>> - at subsection Documentation/Other
>>> + at section Documentation/Other
>>> + at subheading Subscribe to the ffmpeg-devel mailing list.
>>> +It is important to be subscribed to the
>>
>> Of course it is important but I would much, much prefer
>> if people send their patches without being subscribed
>> than not sending their patches because it is implied
>> that they cannot send patches if they don't want to
>> subscribe....
>> But if people are not interested in improving their contribution,
>> I would still prefer the patches to be sent.
>
>
> So, how realistic is this concern about non-subscribers sending patches to
> ffmpeg-devel?  Does it actually happen?

This is very realistic afair.

> Can you point to, say, three patches
> in the last six months which were sent by non-subscribers to ffmpeg-devel

No, the mail admins could (or explain that I am wrong.)

> and were applied to the code base?

I was under the impression the patches that were not
applied would support my point.

> Given how so many of the patches submitted by subscribers who know the
> unwritten rules are subjected to veto and revision, I would be surprised if
> many non-subscribers who are ignorant of the unwritten rules would produce
> something satisfactory.
>
> That said, would your concern be addressed if I were to add this sentence:
>
>    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.

Sure but I was hoping that his is common sense unless explicitely
denied.

>
> (I am tempted to add a phrase like, "If you want to send your patch to
> ffmpeg-devel without discussion, as if  abandoning your baby on the steps of
> the orphanage, please do; one of the kind caregivers on the list may pick it
> up and find it a good home."  But this is probably too snarky to be
> appropriate.)

No objections;-)

>>> + at uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel,
>>> ffmpeg-devel}
>>> +mailing list, because any patch you contribute must be sent there
>>
>> No:
>> I believe it is very important that trivial patches are not sent
>> to the development mailing list - its volume is already so big
>> that some patches are sadly (!) forgotten.
>
> Tell me more about the procedure for trivial patches. I have not seen this
> documented, and I don't know about it. Does this apply to occasional
> contributors, or only to trusted experienced ffmpeg project members with
> commit privileges to the repository?

There is a difference between contributors and committers and
this may be the reason for our misunderstanding.

> The proposed text does not distinguish between occasional contributors and
> experienced project members. Maybe it should. I believe that the main
> audience of `doc/developer.html` is new and occasional contributors, because
> the experienced members will have internalised all the undocumented norms,
> and won't be referring to this page.
>
> What revised wording do you propose for the above phrase "any patch you
> contribute must be sent there"?
>
>>> +Also, this list is where bugs and possible improvements or
>>
>> I believe this is misleading or even wrong.
>
> Oh?  I took this wording from the existing
> <http://ffmpeg.org/developer.html#Documentation_002fOther> regarding the
> ffmpeg-cvslog list:
> "Bugs and possible improvements or general questions regarding commits are
> discussed there."
> What is misleading or wrong about this wording? What is your objection?

Bug fixes and patches that implement improvements are discussed on
ffmpeg-devel and therefore, in this specific cases, bugs and possible
improvement are discussed. Bugs without fixes and improvements
without patches should not be discussed on ffmpeg-devel.

> What alternate wording would you propose for this sentence, which describes
> why contributors should pay attention to the content of ffmpeg-devel?
>>>
>>> +general questions regarding commits 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.
>>> +
>
>
> [...]
>
> I think what is important about this new section is that it describes the
> policy and importance of the ffmpeg-devel list. It's interesting that the
> project had not put this into words in the current documentation. I'm trying
> to do that.  Carl Eugen, you are quick to object to what you don't like
> about proposed wording. I think it's especially important that you suggest
> wording that does capture what you do support. You obviously care.

I apparently failed so far to understand the goal of your patch.

Carl Eugen