<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">The fact is that if embedded code copies were prohibited,</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">I can list a couple of source packages to purge from the archive.</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">And that would demotivate more contributors.<br></div></div><div><br></div><div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">The point is that, sometimes disentangling the embedded code</div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">from the upstream source can cost much greater amount of</div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">time and energy from the maintainer. That's somehow harsh</div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">to the contributors. Embedded code copies may have different</div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">and interesting reasons.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">We all like to handle clean and elegant upstreams. But the</div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">fact is that there are always an amount of unelegant upstreams</div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">such as Google (bazel, tensorflow, abseil-cpp), Facebook (pytorch,</div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"> folly) which are quite unfriendly to distributions.</div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">The contributor has only two choices at low cost: 1) totally</div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">ignore this piece of software even if it seemed useful 2) doing</div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">something not quite elegant such as embedding a convenient copy.<br></div></div><div><br></div><div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Speaking of policy, "should" is a good trade-off that I agree with.</div></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 3 Mar 2020 at 04:04, Sean Whitton <<a href="mailto:spwhitton@spwhitton.name">spwhitton@spwhitton.name</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Mo,<br>
<br>
On Tue 03 Mar 2020 at 08:23AM +08, M. Zhou wrote:<br>
<br>
> Eigen3 is used in the core math part of tensorflow. I have limited energy<br>
> to patch these parts from time to time whenever eigen3 gets updated. I<br>
> dislike introducing burden to myself.<br>
><br>
> Please reject it so I can get rid of this burden permanently.<br>
<br>
Rejected per your request, but from my point of view this discussion is<br>
not over -- Policy 4.13 says that packages *should* not use convenience<br>
copies of code, not that they *must* not.<br>
<br>
Thank you for all your work on uploading useful ML packages.<br>
<br>
-- <br>
Sean Whitton<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Best,</div></div>