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