On 14.01.2019 17:20, Nicolas George wrote:
Tobias Rapp (12019-01-14):
Writing good code requires time. I don't see how being sponsored for
development should have a negative correlation (in general) to the time
invested on a specific topic/patch.
Let us say somebody worked one day on a sponsor
Hi,
On Mon, Jan 14, 2019 at 11:13 AM Nicolas George wrote:
> Ronald S. Bultje (12019-01-13):
> > Wait, what? *You* are suggesting a policy change, not me/us. There is no
> > burden of proof on me. You have to convince me (and us) that your problem
> > is important and your proposal solves the pr
Tobias Rapp (12019-01-14):
> Writing good code requires time. I don't see how being sponsored for
> development should have a negative correlation (in general) to the time
> invested on a specific topic/patch.
Let us say somebody worked one day on a sponsored patch. They now have
two choices:
- s
Ronald S. Bultje (12019-01-13):
> Wait, what? *You* are suggesting a policy change, not me/us. There is no
> burden of proof on me. You have to convince me (and us) that your problem
> is important and your proposal solves the problem. I am not convinced.
I gave arguments in the commit message. Te
On 13.01.2019 16:24, Nicolas George wrote:
James Almer (12019-01-13):
How is that related to sponsored work? If a patch was ignored, then the
extra line in the commit message would have been ignored as much as the
actual code.
Without sponsoring, most reasons for developing code are positively
On 13.01.2019 15:07, Gyan wrote:
On 13-01-2019 06:39 PM, Ronald S. Bultje wrote:
Hi,
On Sun, Jan 13, 2019 at 4:39 AM Gyan wrote:
When someone submits a patch, it is implicit, unless stated otherwise,
that it is of their own initiative (and their own work), and thus they
are free to assign c
On Sun, Jan 13, 2019 at 9:38 AM Nicolas George wrote:
> Derek Buitenhuis (12019-01-13):
> > This is a policy change, not a techncal change.
>
> Policy changes need to be motivated too.
>
Wait, what? *You* are suggesting a policy change, not me/us. There is no
burden of proof on me. You have to c
James Almer (12019-01-13):
> A temporal ban for first time offenders and such could maybe work. But
> then we're back to the CoC discussion that went nowhere.
And look who blocked this...
> And again, you think requesting the disclosure of the incentive behind
> the patch will make a difference o
Michael Niedermayer (12019-01-13):
> You should add yourself to
> https://ffmpeg.org/consulting.html
>
> I have no doubt code you would write for money would be of high quality.
> And more paid developers equal more contributions which is a good thing.
I thank you for your praise, but I will pass
On 1/13/2019 1:29 PM, Nicolas George wrote:
> James Almer (12019-01-13):
>> (1) is not an issue,
>
> It is an issue because it makes the rest possible. After all, people
> whose main motivation is code quality would want their code reviewed.
>
>> (2) and (3) are the issue, an
On Fri, Jan 11, 2019 at 07:21:07PM +0100, Nicolas George wrote:
> Rationale:
>
> * This requirement should offset a little the incentive to neglect
> design, code quality and politeness during the review process when
> done for money.
>
> * The review process itself and future maintenance bur
James Almer (12019-01-13):
> (1) is not an issue,
It is an issue because it makes the rest possible. After all, people
whose main motivation is code quality would want their code reviewed.
> (2) and (3) are the issue, and depending on the
> developer's reaction at reviews an
On 1/13/2019 12:57 PM, Nicolas George wrote:
> James Almer (12019-01-13):
>> And kill the project by reducing development speed to crawl? Unreviewed
>
> That is indeed the problem.
>
>> and unchallenged patches by long time devs with commit rights can and
>> will still be pushed after enough time
On Sun, 13 Jan 2019, 15:57 Nicolas George James Almer (12019-01-13):
> > And kill the project by reducing development speed to crawl? Unreviewed
>
> That is indeed the problem.
>
> > and unchallenged patches by long time devs with commit rights can and
> > will still be pushed after enough time an
James Almer (12019-01-13):
> And kill the project by reducing development speed to crawl? Unreviewed
That is indeed the problem.
> and unchallenged patches by long time devs with commit rights can and
> will still be pushed after enough time and ping attempts have been made.
> Expecting anything
On 1/13/2019 12:24 PM, Nicolas George wrote:
> James Almer (12019-01-13):
>> How is that related to sponsored work? If a patch was ignored, then the
>> extra line in the commit message would have been ignored as much as the
>> actual code.
>
> Without sponsoring, most reasons for developing code a
James Almer (12019-01-13):
> How is that related to sponsored work? If a patch was ignored, then the
> extra line in the commit message would have been ignored as much as the
> actual code.
Without sponsoring, most reasons for developing code are positively
correlated with code quality. Not perfec
On 1/13/2019 12:06 PM, Nicolas George wrote:
> James Almer (12019-01-13):
>> If no one challenges, then either no one looked at it, or everyone that
>> looked at it was fine with it. Where is the issue then?
>
> If nobody looked, how can we know there is no obvious security issue?
How is that rel
Derek Buitenhuis (12019-01-13):
> On 13/01/2019 14:52, Nicolas George wrote:
> > Therefore, I ask reasons: if you do not want to disclose your
> > sponsorships, please explain why?
>
> https://en.wikipedia.org/wiki/Nothing_to_hide_argument
Exactly: the "nothing to hide" argument has good refutati
James Almer (12019-01-13):
> If no one challenges, then either no one looked at it, or everyone that
> looked at it was fine with it. Where is the issue then?
If nobody looked, how can we know there is no obvious security issue?
> You're looking for a solution for a problem that doesn't exist.
T
Hendrik Leppkes (12019-01-13):
> You can't ask for arguments then dismiss the ones you are given based
> on your opinions.
I dismiss an opinion based on an opinion. Proof of the fact:
> I consider my finances and employment my own business, and will never
^^
> disclose it on *public* ma
On 1/13/2019 11:06 AM, Nicolas George wrote:
> James Almer (12019-01-13):
>> Be the change you want in the world and post your day job income here
>> for all to see. Otherwise drop this absurd obsession of yours and let
>> people have a peaceful weekend.
>
> Of course:
>
> All that I have receive
On 13/01/2019 14:52, Nicolas George wrote:
> Therefore, I ask reasons: if you do not want to disclose your
> sponsorships, please explain why?
https://en.wikipedia.org/wiki/Nothing_to_hide_argument
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
On Sun, Jan 13, 2019 at 2:40 PM Nicolas George wrote:
>
> James Almer (12019-01-13):
> > I seem to remember the famous votes count voices, if one were to be called.
>
> You should check again, the rules state that mails without arguments do
> not count.
>
> > Nicolas, no one is in favor of this th
Derek Buitenhuis (12019-01-13):
> No, I don't think that, and I think it's offensive to the people who you
> accuse of that.
I do not accuse them of that, but I find the lack of reasons highly
suspicious. Most times somebody wants something but does not give a
reason, it happens that the reason is
On 13/01/2019 14:38, Nicolas George wrote:
> Any unmotivated objection can be interpreted as "I push bad code for a
> quick buck and do not intend to stop", do you not think?
No, I don't think that, and I think it's offensive to the people who you
accuse of that.
- Derek
_
Derek Buitenhuis (12019-01-13):
> This is a policy change, not a techncal change.
Policy changes need to be motivated too.
Any unmotivated objection can be interpreted as "I push bad code for a
quick buck and do not intend to stop", do you not think?
Regards,
--
Nicolas George
signature.as
On 13/01/2019 13:18, Nicolas George wrote:
> I seem to remember that arguments count, not voices. I have given
> several arguments in the commit message, almost none of them were
> addressed and the dissenting arguments were feeble at best.
This is a policy change, not a techncal change.
- Derek
On 13-01-2019 06:39 PM, Ronald S. Bultje wrote:
Hi,
On Sun, Jan 13, 2019 at 4:39 AM Gyan wrote:
When someone submits a patch, it is implicit, unless stated otherwise,
that it is of their own initiative (and their own work), and thus they
are free to assign copyright. When work is performed f
James Almer (12019-01-13):
> Be the change you want in the world and post your day job income here
> for all to see. Otherwise drop this absurd obsession of yours and let
> people have a peaceful weekend.
Of course:
All that I have received related to my work on FFmpeg is:
- coverage of my expan
On 1/13/2019 10:40 AM, Nicolas George wrote:
> James Almer (12019-01-13):
>> I seem to remember the famous votes count voices, if one were to be called.
>
> You should check again, the rules state that mails without arguments do
> not count.
>
>> Nicolas, no one is in favor of this thing. It's an
James Almer (12019-01-13):
> I seem to remember the famous votes count voices, if one were to be called.
You should check again, the rules state that mails without arguments do
not count.
> Nicolas, no one is in favor of this thing. It's an invasion of privacy
I do not consider this specific poi
On 1/13/2019 10:18 AM, Nicolas George wrote:
> Ronald S. Bultje (12019-01-13):
>> But we don't do copyright assignment.
>
> There have been efforts of relicensing in the past.²
>
>> Anyway, like several others, I'm against this proposal.
>
> I seem to remember that arguments count, not voices.
On 1/13/19, Nicolas George wrote:
> Ronald S. Bultje (12019-01-13):
>> But we don't do copyright assignment.
>
> There have been efforts of relicensing in the past.²
>
>> Anyway, like several others, I'm against this proposal.
>
> I seem to remember that arguments count, not voices. I have given
>
Ronald S. Bultje (12019-01-13):
> But we don't do copyright assignment.
There have been efforts of relicensing in the past.²
> Anyway, like several others, I'm against this proposal.
I seem to remember that arguments count, not voices. I have given
several arguments in the commit message, almost
Hi,
On Sun, Jan 13, 2019 at 4:39 AM Gyan wrote:
> When someone submits a patch, it is implicit, unless stated otherwise,
> that it is of their own initiative (and their own work), and thus they
> are free to assign copyright. When work is performed for hire, the
> copyright may belong to the emp
Gyan (12019-01-13):
> One angle that I haven't seen brought up is legal encumbrance.
>
> When someone submits a patch, it is implicit, unless stated otherwise, that
> it is of their own initiative (and their own work), and thus they are free
> to assign copyright. When work is performed for hire,
On 12-01-2019 12:51 AM, Hendrik Leppkes wrote:
To take a line from your post:
Are you against privacy?
Patches should generally be considered on their own merit. Any such
information will only bias any discussions and result in more
conflict.
One angle that I haven't seen brought up is lega
On 1/12/19, Nicolas George wrote:
> Hendrik Leppkes (12019-01-11):
>> Its everyones right to keep their finances private. Would I be forced
>> to disclose my hourly wages and then determine how long I worked on a
>> patch, just because I did it during my day job? Thats not going to
>> happen.
>>
>
Kyle Swanson (12019-01-11):
> If someone sends a bad patch, we have no obligation to merge it.
Except if they push it themselves after a few hours without review (or
after being rude to somebody to made a review requiring more work).
The disclosure (and review) requirement is especially important
Hendrik Leppkes (12019-01-11):
> Its everyones right to keep their finances private. Would I be forced
> to disclose my hourly wages and then determine how long I worked on a
> patch, just because I did it during my day job? Thats not going to
> happen.
>
> To take a line from your post:
> Are you
> > Signed-off-by: Nicolas George
> > ---
> > doc/developer.texi | 10 ++
> > 1 file changed, 10 insertions(+)
>
> Rather than repeat myself, I'll refer to my previous mails:
>
> * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html
> * http://ffmpeg.org/pipermail/ff
On Fri, Jan 11, 2019 at 8:05 PM Nicolas George wrote:
>
> On the other hand, I have observed in the past patches that were of poor
> quality and suspected they were the result of sponsorships. I would like
> to know. Would you not?
>
Wanting to know and forcing everyone to tell you are two entire
Hi,
On Fri, Jan 11, 2019 at 11:05 AM Nicolas George wrote:
>
> Kyle Swanson (12019-01-11):
> > Lots of people get paid to work on OSS. It's not a conspiracy, that's
> > just the way it is. If someone gets paid to write a patch that does
> > something useful, great. They got paid, and FFmpeg is be
Kyle Swanson (12019-01-11):
> Lots of people get paid to work on OSS. It's not a conspiracy, that's
> just the way it is. If someone gets paid to write a patch that does
> something useful, great. They got paid, and FFmpeg is better. If
> someone gets paid to write a patch that's no good, we just d
On Fri, Jan 11, 2019, at 9:21 AM, Nicolas George wrote:
>
> Signed-off-by: Nicolas George
> ---
> doc/developer.texi | 10 ++
> 1 file changed, 10 insertions(+)
I am against this and completely agree with Derek and Kyle.
___
ffmpeg-devel mailin
On Fri, 11 Jan 2019 at 18:38, Derek Buitenhuis
wrote:
> On 11/01/2019 18:21, Nicolas George wrote:
> > Signed-off-by: Nicolas George
> > ---
> > doc/developer.texi | 10 ++
> > 1 file changed, 10 insertions(+)
>
> Rather than repeat myself, I'll refer to my previous mails:
>
> * htt
Hi,
On Fri, Jan 11, 2019 at 10:21 AM Nicolas George wrote:
>
> Rationale:
>
> * This requirement should offset a little the incentive to neglect
> design, code quality and politeness during the review process when
> done for money.
>
> * The review process itself and future maintenance burden
On 11/01/2019 18:21, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> doc/developer.texi | 10 ++
> 1 file changed, 10 insertions(+)
Rather than repeat myself, I'll refer to my previous mails:
* http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html
* htt
Rationale:
* This requirement should offset a little the incentive to neglect
design, code quality and politeness during the review process when
done for money.
* The review process itself and future maintenance burden cost efforts
to the whole project; knowing that sponsorship has been giv
50 matches
Mail list logo
