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

[Michael Niedermayer]

On Wed, Nov 29, 2017 at 01:06:06PM -0800, Jim DeLaHunt wrote:
> On 2017-11-29 06:53, Compn wrote:
> 
> >[...]
> >>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.
> >[...]
> >Also please note that most ffmpeg developers and patch authors are from
> >around the world , and english may not be their native language.
> I'd be happy to work on better wording. I think the obstacle is more
> fundamental: there isn't agreement on what to say, or a consensus
> that it should be said at all.
> 
> >
> >>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. :)
> 
> What this says to me is that the problems I observe in
> ffmpeg.org/developer.html go deeper than wording.
> 
> There are architectural problems: this one page is supposed to serve
> as both the reference for the project's rules and as a tutorial for
> new contributors. The requirements for these two purposes differ.
> 

> There are governance problems: rules exist for important parts of
> the project, but they are not in writing. Exhibit 1 is that the
> ffmpeg-devel list is central to this project, but there is presently
> zero description of it in this web page. Exhibit 2 is that the
> actual practice of the ffmpeg-cvslog list by several senior
> developers clearly differs from the description of it in this page.

the cvslog list was in the past used in a way thats more
similar to the text, practice changed, probably primarly as the tools
changed from cvs to svn to git.
git has a local, efficient and fast log where one can see all changes.
the prior version control systems lacked that, this may have been
te reason cvslog was more used and important.

The text maybe doesn fully reflect this but it is wrong towards a
arguably benefitial side. That is when more people look & review changes
which are pushed, that is a good thing.

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jim DeLaHunt]

On 2017-11-29 06:53, Compn wrote:


[...]

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.
[...]
Also please note that most ffmpeg developers and patch authors are from
around the world , and english may not be their native language.
I'd be happy to work on better wording. I think the obstacle is more 
fundamental: there isn't agreement on what to say, or a consensus that 
it should be said at all.





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. :)


What this says to me is that the problems I observe in 
ffmpeg.org/developer.html go deeper than wording.


There are architectural problems: this one page is supposed to serve as 
both the reference for the project's rules and as a tutorial for new 
contributors. The requirements for these two purposes differ.


There are governance problems: rules exist for important parts of the 
project, but they are not in writing. Exhibit 1 is that the ffmpeg-devel 
list is central to this project, but there is presently zero description 
of it in this web page. Exhibit 2 is that the actual practice of the 
ffmpeg-cvslog list by several senior developers clearly differs from the 
description of it in this page. Exhibit 3 is the absence in this whole 
discussion of any reference to any rule-making process and its 
decisions, when the patch appears to intrude on policy matters.


There are process problems: while I see lots of activity and appropriate 
process for improving the code of the ffmpeg executables, there is not 
similar activity or appropriate process for improving the documentation. 
I think this thread shows that the patch/review/reject or accept model 
used for code doesn't work so well for words.


And then there are the writing problems: broken links, all content under 
one @chapter, checklists but no instructions to use the checklists, 
missing content, unclear content, and so on.


I came here to try to fix the most severe, easiest to fix bugs in the 
docs. I am learning that nothing about ffmpeg.org/developer.html is 
going to be easy to fix.  I am skeptical that splitting the docs patch 
will help.



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 :)


I appreciate that offer. I will hop on to IRC and off-list email for a 
bit, and see if I can find a way forward. Maybe I won't find it.


In the meantime, I don't expect that I will get the cooperation needed 
to fix this patch. I think it has been defeated.


But I do appreciate the helpful explanation, and I do appreciate the 
welcome to the project. Thank you. Best regards,

   —Jim DeLaHunt

--
--Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [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
 wrote:

> On 2017-11-27 15:00, Carl Eugen Hoyos wrote:
> > 2017-11-26 22:44 GMT+01:00 Jim DeLaHunt :
> >> 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 

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

[Jim DeLaHunt]

On 2017-11-27 15:00, Carl Eugen Hoyos wrote:

2017-11-26 22:44 GMT+01:00 Jim DeLaHunt :
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.


So I will revise the patch to add this paragraph (indented below):


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.

On 2017-11-27 15:00, Carl Eugen Hoyos wrote:

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


Carl Eugen, you have a tremendous dedication to the FFmpeg project and 
are deeply familiar with patch handling and the code base. I would argue 
that this makes you a weaker judge of "common sense". Your sense of what 
is common might be biased by how much you know.


Someone who knows much less might be a better judge of what is "common 
sense" to the new contributor to FFmpeg. And I am here to tell you that 
the paragraphs in this patch are not at all "common sense". New 
contributors need to them said out loud.


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


On 2017-11-27 15:00, Carl Eugen Hoyos wrote:

2017-11-26 22:44 GMT+01:00 Jim DeLaHunt :

On 2017-11-26 03:42, Carl Eugen Hoyos wrote:

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.


[...]


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.

OK, would you accept this wording for a subheading on ffmpeg-devel?

-
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.
-

Carl Eugen, do you accept this wording for a description of ffmpeg-devel 
on ffmpeg.org/developer.html?


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


I answered this in a private email, but the list saw your comment, and 
I'd like it to see my response. Forgive the repetition.


I made this patch because I want to fix bugs in 
ffmpeg.org/developer.html . The website directs new contributors to this 
page, where they are supposed to find out how the project wants them to 
contribute. I am a new contributor, I have just gone through this 
process. I had basic questions which the web page did not answer, or 
answered unhelpfully.


There are shallow, easy-to-fix bugs in the content of this web page. It 
does describe the ffmpeg-cvslog list, using words which are inaccurate 
when compared to the discussion now on the -devel list about how 
committers and contributers use or ignore -cvslog. The page does not 
describe the ffmpeg-devel list, but it should. References to -devel are 
not the same as a description of -devel.


Also, there are editorial problems with the web page. The structure 
consists of one @chapter and multiple @sections and @subsections. The 
structure should be multiple @chapters, so the stub @chapter should be 
eliminated and every @section and @subsection should be promoted one level.


There is a saying in free software, "scratch your own itch". My "itch" 
is that I attempted to make a minor patch to the FFmpeg documentation (2 
new FAQs), and I found it way more difficult than it should have been, 

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

[Lou Logan]

On Mon, Nov 27, 2017, at 02:22 PM, Lou Logan wrote:
>
> To clarify, in this case it was a reply, not a message.

Should have typed "patch" there, not message.

Actually reading message before sending this time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Lou Logan]

On Mon, Nov 27, 2017, at 02:19 PM, 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).

To clarify, in this case it was a reply, not a message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Lou Logan]

On Mon, Nov 27, 2017, at 02:00 PM, Carl Eugen Hoyos wrote:
> No, the mail admins could (or explain that I am wrong.)

I would have to check each sender manually to see if they are in the
membership database. It would be possible to do this, but not very
practical. It would be easier for me to keep a running tally as I clear
the queue. 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).

Sometimes I'll set a frequent non-subscribed senders email address to be
automatically accepted (I purge this list occasionally).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [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 :
> On 2017-11-26 03:42, Carl Eugen Hoyos wrote:
>>
>> 2017-11-26 9:31 GMT+01:00 Jim DeLaHunt :
>>>
>>> -@subsection Documentation/Other
>>> +@section Documentation/Other
>>> +@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;-)

>>> +@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
>  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 

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

[Jim DeLaHunt]

On 2017-11-26 03:42, Carl Eugen Hoyos wrote:

2017-11-26 9:31 GMT+01:00 Jim DeLaHunt :

-@subsection Documentation/Other
+@section Documentation/Other
+@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? Can you point to, say, three 
patches in the last six months which were sent by non-subscribers to 
ffmpeg-devel and were applied to the code base?


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.

(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.)



+@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?


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 
 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?

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.


Best regards,
 —Jim DeLaHunt

--
--Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel