| 1 |
Ühel kenal päeval, K, 30.11.2016 kell 21:23, kirjutas Andrey Utkin: |
| 2 |
> My PR: https://github.com/gentoo/gentoo/pull/2765 |
| 3 |
> |
| 4 |
> My bugzilla ticket linked to it: |
| 5 |
> https://bugs.gentoo.org/show_bug.cgi?id=599088 |
| 6 |
> |
| 7 |
> After my pull request from Nov 6, the following commit gets into |
| 8 |
> mainline: |
| 9 |
> |
| 10 |
> commit e19f46dfca967f4195eedf3f37a7882fbb37b796 |
| 11 |
> Author: Matthew Thode <prometheanfire@g.o> |
| 12 |
> Date: Tue Nov 15 13:55:17 2016 -0600 |
| 13 |
> |
| 14 |
> dev-python/secretstorage: adding for keyring |
| 15 |
> |
| 16 |
> Package-Manager: portage-2.3.0 |
| 17 |
> |
| 18 |
> |
| 19 |
> The difference between my submission and final variant by Matthew is |
| 20 |
> big |
| 21 |
> in number of lines, but is trivial in content as you can see below, |
| 22 |
> so I |
| 23 |
> don't believe that Matthew has written his variant from scratch on |
| 24 |
> his |
| 25 |
> own (he hasn't given any note on tickets on bugs.g.o or github), it |
| 26 |
> seems more like intentional swapping and amending original lines |
| 27 |
> retaining identical outcome. |
| 28 |
|
| 29 |
The diff posted shows almost the maximum amount of differences possible |
| 30 |
for an ebuild of this kind imho. There literally is nothing else than |
| 31 |
usage of eclasses and listing of depends, and all the spacing and some |
| 32 |
order is different even there. If I go and create an ebuild from |
| 33 |
scratch without being aware at all of any other ebuild for it being |
| 34 |
there and never having looked at either, it would probably be either |
| 35 |
identical to yours, or identical to Matthew's. |
| 36 |
So I would say it is entirely possible he simply did not know of the |
| 37 |
existing work and just created a simple ebuild from scratch. |
| 38 |
This work itself is something I wouldn't even consider copyrightable |
| 39 |
(as mentioned in some other threads on that topic). |
| 40 |
|
| 41 |
That said, if the existing work was being based on, attribution should |
| 42 |
have been done, but that's something only he knows if he looked at your |
| 43 |
work or not. He seems to have had to add it as a keyring dep; given |
| 44 |
it's simplicity, might have just done the ebuild from scratch in 5 |
| 45 |
minutes. |
| 46 |
At least after (or rather before) doing the work, searching for |
| 47 |
existing bugzilla bugs for that package would have been nice. |
| 48 |
|
| 49 |
The first occurrence seems to have more merit for concern, as it is a |
| 50 |
recorded fact that your work was looked upon for doing it. However it |
| 51 |
does give credit in the commit message (even summary), just no |
| 52 |
authorship information towards you in git metadata, as your ideas were |
| 53 |
taken and rewritten (new authorship) on top of existing release ebuild |
| 54 |
and credited as a link to the PR. For perfection, a Thanks tag or some |
| 55 |
other tag towards you (Cc?) by name and e-mail would have been nice, |
| 56 |
though. |
| 57 |
|
| 58 |
Overall, it is very appreciated you are contributing, and it does bring |
| 59 |
up a topic we should be more careful about in general. Maybe some |
| 60 |
documentation and part of quizzes for push access even. |
| 61 |
Though the individual cases here brought as example seem not a big |
| 62 |
point of concern (in one case a credit was given, in a way; in the |
| 63 |
other it might have been very well individual work), but I do think |
| 64 |
there could very easily be cases of developers taking someone's work |
| 65 |
and not thinking of proper attribution, even if just from not thinking |
| 66 |
about it. |
| 67 |
|
| 68 |
|
| 69 |
|
| 70 |
Thanks for your contributions! |
| 71 |
|
| 72 |
|
| 73 |
Mart |
Archives