| Message ID | 20190111182107.17397-1-george@nsup.org |
|---|---|
| State | New |
| Headers | show |
On 11/01/2019 18:21, Nicolas George wrote: > Signed-off-by: Nicolas George <george@nsup.org> > --- > 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/ffmpeg-devel/2019-January/238743.html I utterly and absolutely think no good will come from such a policy. It's divisive, exclusionary, inflamatory, witch-hunt-y, and privacy invading, among other things. I'm speechless. Words cannot describe how terrible I think such a policy is for current and future contributors, and I am of the opinion that adopting such a policy would see any work sent to FFmpeg by anyone involved in a company, which I may add, is a lot, utterly dry up. I've not much more to say on the matter, and I will not engage in flame wars after. - Derek (P.S. Just how do you intend to enforce this? How do you prove/disprove someone has been paid in some form, directly, or indiectly? Do you just accuse them on the list?) (P.P.S. I am aware my opinions hold little clout here nowadays, so take my response as you will.)
Hi, On Fri, Jan 11, 2019 at 10:21 AM Nicolas George <george@nsup.org> 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 cost efforts > to the whole project; knowing that sponsorship has been given, to an > individual or to the whole project, helps evaluating if the benefits > match the costs. > > * Inclusion in FFmpeg implies implicit endorsement by the project; > we owe to our users to disclose when this endorsement is not genuine; > this is to relate to mandatory flagging of advertisement in mass media. > > * Systematic disclosure and transparency make a stronger position > against accusations of bias or conflict of interest for difficult > policy decisions. > > * Documenting bounties may give an incentive to new contributors > who may not be aware of these opportunities. > > Signed-off-by: Nicolas George <george@nsup.org> > --- > doc/developer.texi | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/doc/developer.texi b/doc/developer.texi > index 5c342c9106..1d77250083 100644 > --- a/doc/developer.texi > +++ b/doc/developer.texi > @@ -420,6 +420,13 @@ your name after it. > If at some point you no longer want to maintain some code, then please help in > finding a new maintainer and also don't forget to update the @file{MAINTAINERS} file. > > +@subheading Disclose sponsors and other remunerations > +If the patch is the result of sponsored work, expects a bounty or benefited > +from any kind of specific remuneration or payment, include the identity of > +the sponsors, the identity of the recipients (if it is not exactly the > +author of the patch) and the amount (or an approximation if it is not > +possible to define it exactly) in the commit message. > + > We think our rules are not too hard. If you have comments, contact us. > > @chapter Code of conduct > @@ -664,6 +671,9 @@ are notoriously left unchecked, which is a serious problem. > @item > Test your code with valgrind and or Address Sanitizer to ensure it's free > of leaks, out of array accesses, etc. > + > +@item > +Did you disclose any sponsorship in the commit message? > @end enumerate > > @chapter Patch review process > -- > 2.20.1 > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 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 don't merge it. I don't see any reason FFmpeg should be concerned who is getting paid and how much. Thanks, Kyle
On Fri, 11 Jan 2019 at 18:38, Derek Buitenhuis <derek.buitenhuis@gmail.com> wrote: > On 11/01/2019 18:21, Nicolas George wrote: > > Signed-off-by: Nicolas George <george@nsup.org> > > --- > > 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/ffmpeg-devel/2019-January/238743.html > > I utterly and absolutely think no good will come from such a policy. It's > divisive, exclusionary, inflamatory, witch-hunt-y, and privacy invading, > among other things. > > I'm speechless. Words cannot describe how terrible I think such a policy is > for current and future contributors, and I am of the opinion that adopting > such a policy would see any work sent to FFmpeg by anyone involved in a > company, which I may add, is a lot, utterly dry up. > > I've not much more to say on the matter, and I will not engage in flame > wars after. > > - Derek > > (P.S. Just how do you intend to enforce this? How do you prove/disprove > someone > has been paid in some form, directly, or indiectly? Do you just accuse > them on > the list?) > > (P.P.S. I am aware my opinions hold little clout here nowadays, so take my > response > as you will.) > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I fully agree.
On Fri, Jan 11, 2019, at 9:21 AM, Nicolas George wrote: > > Signed-off-by: Nicolas George <george@nsup.org> > --- > doc/developer.texi | 10 ++++++++++ > 1 file changed, 10 insertions(+) I am against this and completely agree with Derek and Kyle.
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 don't merge > it. I don't see any reason FFmpeg should be concerned who is getting > paid and how much. I agree with that. Only you are suggesting a "conspiracy". I am not suggesting we ban people from getting paid, I am not leading a "witch hunt", I only advocate for transparency and honesty. Are you against transparency and honesty? 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? Regards,
Hi, On Fri, Jan 11, 2019 at 11:05 AM Nicolas George <george@nsup.org> 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 better. If > > someone gets paid to write a patch that's no good, we just don't merge > > it. I don't see any reason FFmpeg should be concerned who is getting > > paid and how much. > > I agree with that. Only you are suggesting a "conspiracy". Sorry, bad word choice. > > I am not suggesting we ban people from getting paid, I am not leading a > "witch hunt", I only advocate for transparency and honesty. > > Are you against transparency and honesty? > > 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? If someone sends a bad patch, we have no obligation to merge it. > > Regards, > > -- > Nicolas George > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Thanks, Kyle
On Fri, Jan 11, 2019 at 8:05 PM Nicolas George <george@nsup.org> 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 entirely different things. 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 against privacy? Patches should generally be considered on their own merit. Any such information will only bias any discussions and result in more conflict. - Hendrik
> > Signed-off-by: Nicolas George <george@nsup.org> > > --- > > 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/ffmpeg-devel/2019-January/238743.html > > I utterly and absolutely think no good will come from such a policy. It's > divisive, exclusionary, inflamatory, witch-hunt-y, and privacy invading, > among other things. > > I'm speechless. Words cannot describe how terrible I think such a policy is > for current and future contributors, and I am of the opinion that adopting > such a policy would see any work sent to FFmpeg by anyone involved in a > company, which I may add, is a lot, utterly dry up. > > I've not much more to say on the matter, and I will not engage in flame > wars after. > > - Derek > > (P.S. Just how do you intend to enforce this? How do you prove/disprove someone > has been paid in some form, directly, or indiectly? Do you just accuse them on > the list?) > > (P.P.S. I am aware my opinions hold little clout here nowadays, so take my response > as you will.) > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel My official contributions to ffmpeg are small and as such there isn't much value in my saying "I agree as well". By now I've got a much longer list of changes that I haven't submitted back as patches to ffmpeg than those where I did. This happened for various reasons none of which to blame ffmpeg for. Many others are doing the same. That leads to fragmentation of the code base of course. Fragmentation is not a bad thing per se - many changes are not suitable for general inclusion. But sometimes it can be even just small things keeping an individual developer from submitting patches back when he's got the option to go with his own "ffmpeg+custom" code base. That kind of fragmentation is bad of course, when the common code base could have benefited from a change. Establishing a "transparency requirement" as described, would set up an additional - for some even huge - impediment for contributing back their work. So, while my consent is surely irrelevant (per my own conviction), I really wonder if such a decision would be good for the project. softworkz
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 against privacy? I grant you these were cheap theatricals. But to answer your question seriously: I am against absolute unconditional privacy, yes. Some things deserve privacy, some things do not; I personally believe that economic matters rather fall in the second category. In the particular instance you are evoking, the commit message could just say "developed as part my regular job at $company", I consider that enough disclosure for the purpose. And I wonder why you would want to keep that much hidden. > Patches should generally be considered on their own merit. That is true. And patches should be reviewed and discussed until they are of top quality. You know as well as me that it is not what is happening: there are too many patches and too little time available from competent developers; as a result, some code of mediocre quality have been pushed, and some committers have explicitly stated they would bypass technical objections to their patches. And now it appears that was the result of sponsorships... Regards,
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 for
people who have commit rights, but it would be unjust to apply to only
us.
Regards,
On 1/12/19, Nicolas George <george@nsup.org> 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. >> >> To take a line from your post: >> Are you against privacy? > > I grant you these were cheap theatricals. But to answer your question > seriously: I am against absolute unconditional privacy, yes. Some things > deserve privacy, some things do not; I personally believe that economic > matters rather fall in the second category. > > In the particular instance you are evoking, the commit message could > just say "developed as part my regular job at $company", I consider that > enough disclosure for the purpose. And I wonder why you would want to > keep that much hidden. > >> Patches should generally be considered on their own merit. > > That is true. And patches should be reviewed and discussed until they > are of top quality. You know as well as me that it is not what is > happening: there are too many patches and too little time available from > competent developers; as a result, some code of mediocre quality have > been pushed, and some committers have explicitly stated they would > bypass technical objections to their patches. And now it appears that > was the result of sponsorships... Citation needed.
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 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, the copyright may belong to the employer. Such sponsored work cannot be 'donated' to the project unless the employer agrees to it - it is not for the patch submitter to decide. In such a scenario, the project should know who holds the copyright and under what terms are they willing to submit a patch. Gyan
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, the copyright may > belong to the employer. Such sponsored work cannot be 'donated' to the > project unless the employer agrees to it - it is not for the patch submitter > to decide. In such a scenario, the project should know who holds the > copyright and under what terms are they willing to submit a patch. Thanks, I had not thought of that. I added this in the commit message: * This information is sometimes necessary to determine exactly who owns the copyright for the new code. Regards,
Hi, On Sun, Jan 13, 2019 at 4:39 AM Gyan <ffmpeg@gyani.pro> 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 employer. Such sponsored work cannot be > 'donated' to the project > But we don't do copyright assignment. Anyway, like several others, I'm against this proposal. Ronald
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 none of them were addressed and the dissenting arguments were feeble at best. Regards,
On 1/13/19, Nicolas George <george@nsup.org> 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 > several arguments in the commit message, almost none of them were > addressed and the dissenting arguments were feeble at best. Patch looks very good to me to get applied.
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. I seem to remember the famous votes count voices, if one were to be called. > I have given > several arguments in the commit message, almost none of them were > addressed and the dissenting arguments were feeble at best. Nicolas, no one is in favor of this thing. It's an invasion of privacy and has no way to be enforced. It will potentially deter contributions and generate bias among reviewers if the patch states it's sponsored nature. The last thing this project needs is more walls and more aggressiveness. You and you alone want this in, and everyone else so far doesn't. It's not making it in.
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 point worthy of privacy protection. > and has no way to be enforced. Are you assuming that the contributors, especially the sponsored ones, are usually dishonest? I do not. The way to "enforce" this is to remind people when something suggests they might have neglected to do it, and expect honesty from them. If you consider the contributors dishonest, a much stronger measure is necessary, I hope you agree. > It will potentially deter contributions And it will potentially attract contributions. > and generate bias among reviewers if the patch states it's sponsored > nature. And correct the bias among submitters when it is. > The last thing this project needs is more walls and more > aggressiveness. > > You and you alone want this in, and everyone else so far doesn't. It's > not making it in. Then I will ask you, and everybody who objects, this: How do you propose to address the conflict of interest of a sponsored contributor pushing a patch without review? Regards,
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 invasion of privacy > > I do not consider this specific point worthy of privacy protection. 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. > >> and has no way to be enforced. > > Are you assuming that the contributors, especially the sponsored ones, > are usually dishonest? I do not. The way to "enforce" this is to remind > people when something suggests they might have neglected to do it, and > expect honesty from them. > > If you consider the contributors dishonest, a much stronger measure is > necessary, I hope you agree. > >> It will potentially deter contributions > > And it will potentially attract contributions. > >> and generate bias among reviewers if the patch states it's sponsored >> nature. > > And correct the bias among submitters when it is. > >> The last thing this project needs is more walls and more >> aggressiveness. >> >> You and you alone want this in, and everyone else so far doesn't. It's >> not making it in. > > Then I will ask you, and everybody who objects, this: > > How do you propose to address the conflict of interest of a sponsored > contributor pushing a patch without review? A patch pushed without review, if it gets challenged after the fact, will get reverted unless fixed/addressed, like it happened plenty of times. And it it was pushed while there was considerable opposition before the fact, then they will be penalized with the loss of committing rights for their hubris. This patch of yours brings nothing of value, and will not have any effect on contributors any more than the current state of things (See existing commits in the tree where sponsorship is disclosed without an absurd requirement of having to pull down your pants and bend over like you're requesting here).
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 expanses to attend the VDD; - some t-shirts and a few goodies. The money that I would have received for mentoring in GSoC 2015 was given to the project. Note that I do not make a point of pride of not having gotten much of street value from my work on this project, this is not the reason I do it. But you asked. And to prove I really do not consider this a matter of privacy, I can add my income from not-FFmpeg related: I am a public servant of the French Éducation nationale in the PRAG corps at the salary step 9 with as little overtime as accepted (0-2 hours depending on the year) plus one hour of oral interrogation in prépa and a few yearly hours of coordination with a project. The monetary amounts for all this is of public record. > A patch pushed without review, if it gets challenged after the fact, > will get reverted unless fixed/addressed, like it happened plenty of > times. And who will do the challenging, since we already do not have enough time to review the patches in the first place? Regards,
On 13-01-2019 06:39 PM, Ronald S. Bultje wrote: > Hi, > > On Sun, Jan 13, 2019 at 4:39 AM Gyan <ffmpeg@gyani.pro> 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 employer. Such sponsored work cannot be >> 'donated' to the project >> > But we don't do copyright assignment. No, the patch submitter (implicitly) does. Which is not a problem when the copyright holder and submitter are the same person. For sponsored code, they may not be. Analogy: Scenario 1 A 'vlogger' makes a video and uploads it as public to Youtube. Youtube then lets everyone see that video. No problem. Scenario 2 Someone pays the vlogger to make a video. Vlogger uploads it to YT as public. There's a problem if the client did not allow that which makes it copyright infringement, Which is why YT has this clause in their T&C "You affirm, represent, and warrant that you own or have the necessary licenses, rights, consents, and permissions to publish Content you submit; and you license to YouTube all patent, trademark, trade secret, copyright or other proprietary rights in and to such Content for publication on the Service pursuant to these Terms of Service." So, we are YT in this case and the Content is the patch(es). The concern would be that the submitter doesn't have the right to license the code into ffmpeg, if the contract with the client doesn't allow them to do it. Only way to be sure is for the sponsor to affirm to it. And for that, we would have to know that there is a sponsor, to start with. Gyan
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
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,
On Sun, Jan 13, 2019 at 2:40 PM Nicolas George <george@nsup.org> 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 invasion of privacy > > I do not consider this specific point worthy of privacy protection. > You can't ask for arguments then dismiss the ones you are given based on your opinions. I consider my finances and employment my own business, and will never disclose it on *public* mailing list. Therefor, such a policy is entirely unacceptable. - Hendrik
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): > 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 rather bad. Therefore, I ask reasons: if you do not want to disclose your sponsorships, please explain why? Regards,
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
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 received related to my work on FFmpeg is: > > - coverage of my expanses to attend the VDD; > > - some t-shirts and a few goodies. > > The money that I would have received for mentoring in GSoC 2015 was > given to the project. > > Note that I do not make a point of pride of not having gotten much of > street value from my work on this project, this is not the reason I do > it. But you asked. > > And to prove I really do not consider this a matter of privacy, I can > add my income from not-FFmpeg related: I am a public servant of the > French Éducation nationale in the PRAG corps at the salary step 9 with > as little overtime as accepted (0-2 hours depending on the year) plus > one hour of oral interrogation in prépa and a few yearly hours of > coordination with a project. The monetary amounts for all this is of > public record. > >> A patch pushed without review, if it gets challenged after the fact, >> will get reverted unless fixed/addressed, like it happened plenty of >> times. > > And who will do the challenging, since we already do not have enough > time to review the patches in the first place? 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? You're looking for a solution for a problem that doesn't exist. If a patch is disliked, it will be challenged, regardless of the incentive behind it. If a patch is not challenged, then it was either ignored or liked, and likewise, the incentive behind it had no relevance. This patch you propose will not change that. Sponsored work has been disclosed before without any kind of guidelines. This patch, in its current form, is both unnecessary and completely unacceptable. If you want something people will not NAK on sight, write one where you require to double check who the copyright belongs to in case of sponsorship to prevent wrong commit authorship, and to *suggest* stating sponsorship status if the copyright ultimately belongs to the developer. Drop any mention about remuneration disclosure if it was not public to begin with, and then it can be discussed.
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* mailing list. I do not remember the references, but I have seen at least one, possibly several, serious studies showing that secrecy about salaries caused an overall decrease in salaries and worsening in workplace interaction. It is a management technique of the "divide and conquer" type to avoid workers from organizing to get decent salaries. The only people who should be attached to salary secrecy are the people who at some level realize that they are payed way more than they deserve (finance, marketing, etc.). For people whose work has actual value, like you, this attachment is only the result of propaganda and detrimental to yourself. Regards,
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. Tell that to the people who have been insulted for raising valid objections on sponsored work. > Sponsored work has been disclosed before without any kind of guidelines. Not all of it. > If you want something people will not NAK on sight, write one where you > require to double check who the copyright belongs to in case of > sponsorship to prevent wrong commit authorship, and to *suggest* stating > sponsorship status if the copyright ultimately belongs to the developer. > Drop any mention about remuneration disclosure if it was not public to > begin with, and then it can be discussed. Re-read the rationale in the proposed patch: copyright is only one of them. Regards,
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 refutations in many cases. So please, give the refutations for this case. Regards,
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 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. > >> You're looking for a solution for a problem that doesn't exist. > > Tell that to the people who have been insulted for raising valid > objections on sponsored work. > >> Sponsored work has been disclosed before without any kind of guidelines. > > Not all of it. And that is not going to change no matter how many lines with absurd and unenforceable intrusive requirements you try to add to a file nobody ever reads. > >> If you want something people will not NAK on sight, write one where you >> require to double check who the copyright belongs to in case of >> sponsorship to prevent wrong commit authorship, and to *suggest* stating >> sponsorship status if the copyright ultimately belongs to the developer. >> Drop any mention about remuneration disclosure if it was not public to >> begin with, and then it can be discussed. > > Re-read the rationale in the proposed patch: copyright is only one of > them. And none of them change anything of what i said. You will not magically generate new or better reviews for patches that otherwise would have not gotten any. The patch is unacceptable as is. Rewrite it into something closer to what i mentioned above that encourages developers instead of disturb, disgust and scare them away, and you'll be met with more amenability from other developers in the project.
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 perfectly, but at least some. Sponsorship, on the other hand, is a motivation for developing code that has little to do with code quality. For that reason, sponsored code should be examined much more carefully. Of course, if your stance were that no new code should go in without proper review, then I would support you totally, and possibly drop this proposal. Is it? Regards,
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 are positively > correlated with code quality. Not perfectly, but at least some. > > Sponsorship, on the other hand, is a motivation for developing code that > has little to do with code quality. > > For that reason, sponsored code should be examined much more carefully. > > Of course, if your stance were that no new code should go in without > proper review, then I would support you totally, and possibly drop this > proposal. Is it? And kill the project by reducing development speed to crawl? Unreviewed 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 else will take ffmpeg through the same road libav found itself in. Bad commits that were ignored but noticed after the fact have been reverted in the past. They will inevitably crash under the weight of its own crappiness. That will not change. Rewrite this patch, make it palatable, and then the rest of the project will consider it. Stop wasting your and everyone's time by insisting on a patch everyone NAKed.
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 else will take ffmpeg through the same road libav > found itself in. > Bad commits that were ignored but noticed after the fact have been > reverted in the past. They will inevitably crash under the weight of its > own crappiness. That will not change. > > Rewrite this patch, make it palatable, and then the rest of the project > will consider it. Stop wasting your and everyone's time by insisting on > a patch everyone NAKed. You keep saying that, but you waltz around the problem. So let me state it plainly: If there is somebody (1) who repeatedly pushes patches without review (because it is new code or because it is over code that they maintain by self-appointment), (2) whose patches frequently cause regressions, some of them detected by Coverity, (3) when they get a review and it requires more work from them, are rude and unhelpful, and possibly ignore the comments, (4) as a result from that rudeness receive even less reviews, and (5) all this seems to be motivated by sponsorship, can you tell what course of action you propose? Regards,
On Sun, 13 Jan 2019, 15:57 Nicolas George <george@nsup.org 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 and ping attempts have been made. > > Expecting anything else will take ffmpeg through the same road libav > > found itself in. > > Bad commits that were ignored but noticed after the fact have been > > reverted in the past. They will inevitably crash under the weight of its > > own crappiness. That will not change. > > > > Rewrite this patch, make it palatable, and then the rest of the project > > will consider it. Stop wasting your and everyone's time by insisting on > > a patch everyone NAKed. > > You keep saying that, but you waltz around the problem. So let me state > it plainly: > > If there is somebody (1) who repeatedly pushes patches without review > (because it is new code or because it is over code that they maintain by > self-appointment), (2) whose patches frequently cause regressions, some > of them detected by Coverity, (3) when they get a review and it requires > more work from them, are rude and unhelpful, and possibly ignore the > comments, (4) as a result from that rudeness receive even less reviews, > and (5) all this seems to be motivated by sponsorship, can you tell what > course of action you propose? > How would declaring the sponsorship help in this regard,when the real issue is your points 1 to 4?
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 and ping attempts have been made. >> Expecting anything else will take ffmpeg through the same road libav >> found itself in. >> Bad commits that were ignored but noticed after the fact have been >> reverted in the past. They will inevitably crash under the weight of its >> own crappiness. That will not change. >> >> Rewrite this patch, make it palatable, and then the rest of the project >> will consider it. Stop wasting your and everyone's time by insisting on >> a patch everyone NAKed. > > You keep saying that, but you waltz around the problem. So let me state > it plainly: > > If there is somebody (1) who repeatedly pushes patches without review > (because it is new code or because it is over code that they maintain by > self-appointment), (2) whose patches frequently cause regressions, some > of them detected by Coverity, (3) when they get a review and it requires > more work from them, are rude and unhelpful, and possibly ignore the > comments, (4) as a result from that rudeness receive even less reviews, > and (5) all this seems to be motivated by sponsorship, can you tell what > course of action you propose? (1) is not an issue, (2) and (3) are the issue, and depending on the developer's reaction at reviews and request for fixes, it should result in the removal of commit rights. Have you seen something forcefully pushed after reviews or concerns were ignored by the committer because they capriciously didn't like said reviews or reviewer, that wasn't eventually reverted or adapted? Does the recent patch by Paul that prompted this abomination of a patch fit the above criteria? And (5) is completely irrelevant for the above. Bad code is bad code, and bad behavior is bad behavior, regardless of the incentive behind it. This patch of yours pretends to magically fix (2) to (4) by assuming tackling (5) will have any effect.
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 and request for fixes, it should result > in the removal of commit rights. I was not ready to go that way, but since you put that on the tale, be aware that I will hold you to it. > Does > the recent patch by Paul that prompted this abomination of a patch fit > the above criteria? If they happened in the future and not in the past (decisions should not be retroactive), I would consider this: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237979.html https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/238166.html (I notice that you did call him out on the second, and I appreciate it) to count as strikes one and two. > And (5) is completely irrelevant for the above. Bad code is bad code, > and bad behavior is bad behavior, regardless of the incentive behind it. I am not very surprised to see technical types ignoring sociological evidence, but it is saddening. Regards,
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 burden cost efforts > to the whole project; knowing that sponsorship has been given, to an > individual or to the whole project, helps evaluating if the benefits > match the costs. > > * Inclusion in FFmpeg implies implicit endorsement by the project; > we owe to our users to disclose when this endorsement is not genuine; > this is to relate to mandatory flagging of advertisement in mass media. > > * Systematic disclosure and transparency make a stronger position > against accusations of bias or conflict of interest for difficult > policy decisions. > > * Documenting bounties may give an incentive to new contributors > who may not be aware of these opportunities. > > Signed-off-by: Nicolas George <george@nsup.org> > --- > doc/developer.texi | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/doc/developer.texi b/doc/developer.texi > index 5c342c9106..1d77250083 100644 > --- a/doc/developer.texi > +++ b/doc/developer.texi > @@ -420,6 +420,13 @@ your name after it. > If at some point you no longer want to maintain some code, then please help in > finding a new maintainer and also don't forget to update the @file{MAINTAINERS} file. > > +@subheading Disclose sponsors and other remunerations > +If the patch is the result of sponsored work, expects a bounty or benefited > +from any kind of specific remuneration or payment, include the identity of > +the sponsors, the identity of the recipients (if it is not exactly the > +author of the patch) and the amount (or an approximation if it is not > +possible to define it exactly) in the commit message. > + > We think our rules are not too hard. If you have comments, contact us. > > @chapter Code of conduct > @@ -664,6 +671,9 @@ are notoriously left unchecked, which is a serious problem. > @item > Test your code with valgrind and or Address Sanitizer to ensure it's free > of leaks, out of array accesses, etc. > + > +@item > +Did you disclose any sponsorship in the commit message? > @end enumerate > > @chapter Patch review process 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. Also iam not sure how this change would interact with the GDPR or a NDA iam no lawyer .... Thanks [...]
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, and depending on the >> developer's reaction at reviews and request for fixes, it should result >> in the removal of commit rights. > > I was not ready to go that way, but since you put that on the tale, be > aware that I will hold you to it. And what was your idea, if not that? You complain about people potentially forcefully pushing patches after ignoring NAKs or request for fixes. If the person can't be convinced to stop doing that, what else can you do to stop them? A temporal ban for first time offenders and such could maybe work. But then we're back to the CoC discussion that went nowhere. > >> Does >> the recent patch by Paul that prompted this abomination of a patch fit >> the above criteria? > > If they happened in the future and not in the past (decisions should not > be retroactive), I would consider this: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237979.html > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/238166.html > > (I notice that you did call him out on the second, and I appreciate it) > to count as strikes one and two. > >> And (5) is completely irrelevant for the above. Bad code is bad code, >> and bad behavior is bad behavior, regardless of the incentive behind it. > > I am not very surprised to see technical types ignoring sociological > evidence, but it is saddening. And again, you think requesting the disclosure of the incentive behind the patch will make a difference on the behavior of a person questioned for ignoring reviews? On top of being unacceptable in its current form, this patch is evidently misguided.
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. Like... absolutely every adult in the developed world, my relation to money is deeply neurotic, and I do not want to subject myself to the conflicting urges that it would cause. This is one of the main reasons I want to keep my livelihood to come from teaching as a public servant: doing my job well does not lower my income. The world at large would be much better if people were to realize how neurotic their relation with money is. But this is getting far from the topic of this list. Regards,
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 on the behavior of a person questioned > for ignoring reviews? So you think they would outright lie about their sponsorships? I am more optimistic: I believe there is a core of honesty and attachment to good code in most contributors, and that making them aware of their bias would be enough to convince them to try to do better, at least a start. But if you think they are actually dishonest and neglectful, then I concur with your conclusions: they have no business having commit rights. Regards,
On Sun, Jan 13, 2019 at 9:38 AM Nicolas George <george@nsup.org> 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 convince me (and us) that your problem is important and your proposal solves the problem. I am not convinced. Ronald
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 <ffmpeg@gyani.pro> 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 employer. Such sponsored work cannot be >>> 'donated' to the project >>> >> But we don't do copyright assignment. > > > No, the patch submitter (implicitly) does. Which is not a problem when > the copyright holder and submitter are the same person. For sponsored > code, they may not be. > > Analogy: > > Scenario 1 > > A 'vlogger' makes a video and uploads it as public to Youtube. Youtube > then lets everyone see that video. No problem. > > Scenario 2 > > Someone pays the vlogger to make a video. Vlogger uploads it to YT as > public. There's a problem if the client did not allow that which makes > it copyright infringement, Which is why YT has this clause in their T&C > > "You affirm, represent, and warrant that you own or have the necessary > licenses, rights, consents, and permissions to publish Content you > submit; and you license to YouTube all patent, trademark, trade secret, > copyright or other proprietary rights in and to such Content for > publication on the Service pursuant to these Terms of Service." > > So, we are YT in this case and the Content is the patch(es). The concern > would be that the submitter doesn't have the right to license the code > into ffmpeg, if the contract with the client doesn't allow them to do > it. Only way to be sure is for the sponsor to affirm to it. And for > that, we would have to know that there is a sponsor, to start with. Isn't this what the "Signed-off-by" line in a commit already states? So to solve this (if actually deemed necessary) it would be better to request the commit author to signal that the copyright status has been clarified by always adding this Signed-off-by line instead. Regards, Tobias
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 > correlated with code quality. Not perfectly, but at least some. > > Sponsorship, on the other hand, is a motivation for developing code that > has little to do with code quality. > > For that reason, sponsored code should be examined much more carefully. 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. Patch review intensity should be based on the content of the patch itself (e.g. complexity and long-term maintenance factor) and not based on some disclosure requirement that has the potential to support prejudice. Best regards, Tobias
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. Tell me what exactly you find unconvincing in them, and I can elaborate. But just "I am not convinced" is not how debating works. Regards,
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: - spend another day refactoring the code, designing functions API so that they can be shared with existing code; - submit as is and start working on a new patch for a new sponsorship. Which one will be more attractive? Of course, the same could apply to « start working on a new feature », but the value of refactoring and clean code for new features is more obvious. Also, if the code becomes less readable, more complex, then knowing it well becomes more valuable, in a marketable sense. Regards,
Hi, On Mon, Jan 14, 2019 at 11:13 AM Nicolas George <george@nsup.org> 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 problem. I am not convinced. > > I gave arguments in the commit message. Tell me what exactly you find > unconvincing in them, and I can elaborate. But just "I am not > convinced" is not how debating works. > You have seen a few bad-quality patches, and you now assume that there is (1) a correlation between bad patch quality and sponsorship and (2) that disclosure of sponsorship details will somehow address this constructively. I am unconvinced of both. For (1), specifically, you have only given anecdotical evidence, and you have not used any anecdotical evidence to the contrary, even though it exists in plain sight. For example, some of my patches have been sponsored. Are they bad quality? Which ones (I'd like to see if you can point out my sponsored vs. unsponsored patches based on your metric of poor patch quality)? I would like to see evidence that goes beyond anecdotes and holds up when applied to the full git tree. For (2), I am not convinced in particular that requiring people to disclose how much money they earn will make patches better. Quite the contrary, some cultures consider finance a private affair and so I think you'll just chase away valued contributors who have in the past provided very high-quality patches. This goes beyond the mere issue as privacy - which is also important, but is not what I'm talking about here. You claim that requiring people to disclose how much money they make *in particular* will significantly impact patch quality. But you provide no evidence for this claim, not even any anecdotical evidence. It is also not self-evident to me. I think it is merely punitive. Could you provide evidence that requiring people ti disclose how much money they make will improve patch quality? Or is it merely meant to discourage such patch submissions altogether? Ronald
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 sponsored patch. They now have > two choices: > > - spend another day refactoring the code, designing functions API so > that they can be shared with existing code; > > - submit as is and start working on a new patch for a new sponsorship. > > Which one will be more attractive? I would assume that a sponsor's interest in sustainability is at least equal to the interest of somebody doing development in free time. At least I don't see an evident point why the interest should be different per se. To me the more helpful discussion would be around how to resolve conflicts during code review and improve patch quality, rather than the influence of sponsorship. Best regards, Tobias
diff --git a/doc/developer.texi b/doc/developer.texi index 5c342c9106..1d77250083 100644 --- a/doc/developer.texi +++ b/doc/developer.texi @@ -420,6 +420,13 @@ your name after it. If at some point you no longer want to maintain some code, then please help in finding a new maintainer and also don't forget to update the @file{MAINTAINERS} file. +@subheading Disclose sponsors and other remunerations +If the patch is the result of sponsored work, expects a bounty or benefited +from any kind of specific remuneration or payment, include the identity of +the sponsors, the identity of the recipients (if it is not exactly the +author of the patch) and the amount (or an approximation if it is not +possible to define it exactly) in the commit message. + We think our rules are not too hard. If you have comments, contact us. @chapter Code of conduct @@ -664,6 +671,9 @@ are notoriously left unchecked, which is a serious problem. @item Test your code with valgrind and or Address Sanitizer to ensure it's free of leaks, out of array accesses, etc. + +@item +Did you disclose any sponsorship in the commit message? @end enumerate @chapter Patch review process
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 given, to an individual or to the whole project, helps evaluating if the benefits match the costs. * Inclusion in FFmpeg implies implicit endorsement by the project; we owe to our users to disclose when this endorsement is not genuine; this is to relate to mandatory flagging of advertisement in mass media. * Systematic disclosure and transparency make a stronger position against accusations of bias or conflict of interest for difficult policy decisions. * Documenting bounties may give an incentive to new contributors who may not be aware of these opportunities. Signed-off-by: Nicolas George <george@nsup.org> --- doc/developer.texi | 10 ++++++++++ 1 file changed, 10 insertions(+)