Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Thu, Oct 27, 2016 at 05:08:13PM -0700, Daniel Campbell wrote: > Forgive me, but I don't see why people have so much trouble with > copyright wrt Gentoo. I've simply assumed anything I wrote for Gentoo > would be attributed to me via git log information and/or metadata.xml > and should I leave Gentoo, Gentoo keeps the rights to it since I'm > contributing to it. Nothing stops me from pushing ebuilds to my personal > overlay *and* the primary Gentoo tree. Note, lots of people (i.e. almost anyone who is employed in the US), are in the situation where the copyright ownership of your contributions are not owned by yourself, so you can not give the copyright away to the Gentoo Foundation without an explicit legal document from that owner granting that copyright transfer (or additional ownership.) So this is a real issue, and a problem, for many of our developers (myself included), which is why many many years ago some of us worked to get that copyright ownership document removed. > With a DCO, it greatly complicates things. Would my right to keep my > contributions in an overlay be infringed upon? What would change if we > switch to this? Nothing, it just explicitly calls out that you know the contribution you are making is allowed and under the license of the file/project you are contributing to. It does not change the ownership of the copyright of the contribution at all. It's a very simple document, I think I've written more words in this email than the whole document has, I suggest reading it for all of the details. thanks, greg k-h
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Thu, Oct 27, 2016 at 8:08 PM, Daniel Campbell wrote: > > With a DCO, it greatly complicates things. Would my right to keep my > contributions in an overlay be infringed upon? What would change if we > switch to this? > The DCO doesn't change your rights at all, or change the status of the copyright. It is simply a declaration that the code is redistributable under the appropriate license. While we don't have a DCO in place currently, it is already policy that devs are supposed to check the license. The FLA does change the status of the copyright/licensing situation. However, this will be voluntary, so if it concerns anybody they simply can choose to sign it. However, under the FLA if you do assign copyright to Gentoo then in accordance with the agreement Gentoo will give you the right to redistribute your code in perpetuity without restriction (if I'm reading it correctly). Essentially you'd be giving Gentoo the right to re-license the code under another FOSS license or pursue copyright claims, but you still will be able to do most of the things you could do if you had retained copyright. Both practices are actually very standard in the FOSS world. The DCO is used by Linux and numerous other projects and is generally considered a best practice for any project. The FLA is less commonly used, but I know that KDE uses it. It is probably more common in community products especially in Europe, since it is designed to handle the German case. I'd say that a CLA is a more common practice, especially in projects that are dual-licensed with a commercial backer. The CLA is a much stronger transfer of the rights of the contributor to the project and usually gives the project a blank check to do whatever they want with the code, such as making it exclusively closed-source in the future. This is obviously desirable to corporate-backed projects as it gives them more options to extract money from the code. The DCO basically is an extra assurance that our copyrights are sound. The FLA is a way to give Gentoo more options for relicensing code and such, but in a way that is more compatible with our social contract and which probably also makes us a less attractive hostile takeover target (since the FLA would limit the sorts of bad things somebody could do with our copyrights if they managed to seize them). Honestly, I think the policy actually does simplify things for the most part by making a lot of things explicit where currently they are vague and where a variety of opinions prevail. However, simplification was never really the main goal of the policy. It is more about not getting sued and being more flexible the next time somebody decides to fork something like udev without starting a fiasco. Since she hasn't promoted it herself, I'll point out that alicef has wikified the policy here: https://wiki.gentoo.org/wiki/User:Aliceinwire/CopyrightPolicy I'll go ahead and make some of the tweaks mentioned in the thread, and maybe try to improve the attribution overhead which I think is the only real downside. I think if it were implemented the contents of that page would probably be split up a bit as it combines very static information (the policy) with things like the table of licenses which obviously will be updated frequently. -- Rich
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/27/2016 08:31 AM, Rich Freeman wrote: > On Thu, Oct 27, 2016 at 11:21 AM, Ulrich Mueller wrote: >> >> I would conclude that the intention is that the whole of the Linux >> kernel can be distributed under the GPL, version 2, unless noted >> otherwise. >> > > Stepping back, I'd just like to comment that while I hold an opinion > on this that is likely different from gregkh, and possibly the Linux > Foundation, I suspect this is going to be moot since as far as I can > tell we aren't modifying the DCO and don't really think we need to. > So, it is probably simpler to avoid controversy by just incorporating > it by reference under their original name, which is certainly the > intention of the Linux Foundation in promoting it. > > I think it is an interesting discussion/debate as to whether the Linux > Foundation has or hasn't effectively released the DCO under the GPL > with no further restrictions. However, I don't think it ultimately is > going to drive what we do. So, we can just have our private opinions > here, and I do get Greg's arguments (and I acknowledge that he is a > bit of an expert in this space). > > I'll just note that tempest in a teapot actually drives home the > importance of explicit copyright and license notices, since it is the > absence of any such notice in this file that is in part driving this > controversy. Some of the potential ambiguities with our own current > policy could create similar issues, and they have in fact gotten > people upset when code was brought into a Gentoo repository without a > good policy on how to handle the copyright notices. > > Authorship and ownership matter to people. A good copyright policy is > about respecting the rights of others as much as preserving our own. > > (And, as always, everything above is just my personal opinion...) > Forgive me, but I don't see why people have so much trouble with copyright wrt Gentoo. I've simply assumed anything I wrote for Gentoo would be attributed to me via git log information and/or metadata.xml and should I leave Gentoo, Gentoo keeps the rights to it since I'm contributing to it. Nothing stops me from pushing ebuilds to my personal overlay *and* the primary Gentoo tree. With a DCO, it greatly complicates things. Would my right to keep my contributions in an overlay be infringed upon? What would change if we switch to this? It's just odd to me that in one case (the comrel deal) we're aiming to simplify, but with copyright we're seemingly complicating things for -- through my perspective -- little gain. Is anyone at Gentoo actually concerned about the copyright of their ebuilds? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
> So, it is probably simpler to avoid controversy by just incorporating > it by reference under their original name, which is certainly the > intention of the Linux Foundation in promoting it. +1 :-) signature.asc Description: PGP signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Thu, Oct 27, 2016 at 11:21 AM, Ulrich Mueller wrote: > > I would conclude that the intention is that the whole of the Linux > kernel can be distributed under the GPL, version 2, unless noted > otherwise. > Stepping back, I'd just like to comment that while I hold an opinion on this that is likely different from gregkh, and possibly the Linux Foundation, I suspect this is going to be moot since as far as I can tell we aren't modifying the DCO and don't really think we need to. So, it is probably simpler to avoid controversy by just incorporating it by reference under their original name, which is certainly the intention of the Linux Foundation in promoting it. I think it is an interesting discussion/debate as to whether the Linux Foundation has or hasn't effectively released the DCO under the GPL with no further restrictions. However, I don't think it ultimately is going to drive what we do. So, we can just have our private opinions here, and I do get Greg's arguments (and I acknowledge that he is a bit of an expert in this space). I'll just note that tempest in a teapot actually drives home the importance of explicit copyright and license notices, since it is the absence of any such notice in this file that is in part driving this controversy. Some of the potential ambiguities with our own current policy could create similar issues, and they have in fact gotten people upset when code was brought into a Gentoo repository without a good policy on how to handle the copyright notices. Authorship and ownership matter to people. A good copyright policy is about respecting the rights of others as much as preserving our own. (And, as always, everything above is just my personal opinion...) -- Rich
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
> On Thu, 27 Oct 2016, Matthias Maier wrote: >> Therefore, we may indeed consider taking the DCO from the Linux source >> tree which is distributed under the GPL-2 > I highly doubt that the DCO in the readme is licensed under GPL-2. There > is no readme/header, or other indicator stating this. Not everything in > the linux repository falls under GPL-2. Few of the files in the Documentation subdir have a license header. It is also missing from various other files (top-level Makefile, for example). Following your reasoning, we would not be permitted to distribute kernel tarballs. So, should we add mirror restriction to sys-kernel/*-sources then? I very much doubt that this is the intention of upstream. I'd rather conclude that they are a bit lax with their headers (as compared to the FSF, for example). Also, in COPYING in the top-level dir there is this: Also note that the GPL below is copyrighted by the Free Software Foundation, but *the instance of code that it refers to (the Linux kernel)* is copyrighted by me and others who actually wrote it. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. [*...* my emphasis, _..._ author's emphasis] I would conclude that the intention is that the whole of the Linux kernel can be distributed under the GPL, version 2, unless noted otherwise. Ulrich pgpdn2yGwz6SD.pgp Description: PGP signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Thu, Oct 27, 2016 at 11:02 AM, Matthias Maier wrote: > > On Thu, Oct 27, 2016, at 09:11 CDT, Rich Freeman wrote: > >> I'd think that the title of a legal document falls more under >> trademark law than copyright law. That is why the FSF publishes the >> "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC >> LICENSE." The former has far more trademark protection than the >> latter. > > What? > > No, this is *not* how it works. > > A license text is an original piece of work that falls under copyright > protection. We're not talking about the text of the license in the paragraph above. We're talking about the title of the license. > In this case the copyright holder is the > > »The Linux Foundation and its contributors«. Well, there is no statement of copyright in this file: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches But, I don't dispute that the Linux Foundation and its contributors hold the copyright. > > The terms of distribution are > > »Everyone is permitted to copy and distribute verbatim copies of this > license document, but changing it is not allowed.« > That text does not appear anywhere in the file I linked. The GPL does, however. > > You cannot simply copy a substantial amount of text into your work (no > matter what it is) if you do not have the right to do so. > I agree. I certainly wouldn't do it if the Linux Foundation hadn't published it under the GPL. >> The Linux Foundation published a version of their DCO under the GPL, >> which we would of course abide by. > > I highly doubt that, see my previous e-mail. > I just linked it, and it was linked in the draft policy. The fact that they published it elsewhere under a different license just means that it is effectively dual-licensed. It doesn't diminish any rights conferred under the GPL. -- Rich
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Thu, Oct 27, 2016 at 10:55 AM, Greg KH wrote: > On Thu, Oct 27, 2016 at 10:11:45AM -0400, Rich Freeman wrote: >> On Thu, Oct 27, 2016 at 9:29 AM, Greg KH wrote: >> > >> > You can't change the text of a license and call it the same thing, >> >> I'd think that the title of a legal document falls more under >> trademark law than copyright law. That is why the FSF publishes the >> "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC >> LICENSE." The former has far more trademark protection than the >> latter. > > Do you see that term trademarked anywhere? I will go file for one if > you really insist on it, but really, think this through please. The term "GNU" is trademarked as far as I'm aware. Or, if not it would probably be trademarkable in this context, since it is fairly unique. The term "General Public License" seems rather, well, general. When your title for something is generic it is generally very difficult to enforce a trademark against it. If you called it the "Linux DCO" then you'd probably have a strong recourse against anybody also using the term "Linux DCO" since Linux is a strong mark (it is a word that Linus invented as far as I'm aware). Look at Microsoft's attempts to enforce trademarks against "windows" for an example of why generic words don't make good marks. > >> > which >> > is why that wording is there (same wording is in the GPL), so don't >> > think that by pointing at the one in the kernel source tree that changes >> > anything... >> >> The Linux Foundation published a version of their DCO under the GPL, >> which we would of course abide by. The fact that they published it >> elsewhere with a different license doesn't mean that we can't re-use >> the version published under the GPL. > > How well does "plain text" work under the GPL? Go on, I've been down > that path before, it's well-worn, we'll be here when you get back... :) Well, whether the GPL is a good license for text is a separate matter, but it is a license. > >> If we aren't changing anything that does raise the question of why not >> just use the Linux DCO, v1.1 or whatever it is at, incorporated by >> reference. I do think we have the legal right to fork it since it was >> effectively published by the Linux Foundation under the GPL, but that >> doesn't require us to fork it. > > Please just use the one as-published. > Seems like a logical approach. -- Rich
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Thu, Oct 27, 2016, at 09:11 CDT, Rich Freeman wrote: > I'd think that the title of a legal document falls more under > trademark law than copyright law. That is why the FSF publishes the > "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC > LICENSE." The former has far more trademark protection than the > latter. What? No, this is *not* how it works. A license text is an original piece of work that falls under copyright protection. In this case the copyright holder is the »The Linux Foundation and its contributors«. The terms of distribution are »Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.« You cannot simply copy a substantial amount of text into your work (no matter what it is) if you do not have the right to do so. > The Linux Foundation published a version of their DCO under the GPL, > which we would of course abide by. I highly doubt that, see my previous e-mail. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Thu, Oct 27, 2016 at 04:41:37PM +0200, Ulrich Mueller wrote: > > On Thu, 27 Oct 2016, Greg KH wrote: > > >> Also, I wouldn't completely exclude that we need to change the > >> wording at some later point. Therefore, we may indeed consider > >> taking the DCO from the Linux source tree which is distributed > >> under the GPL-2, instead of the non-free version ("changing it is > >> not allowed") from developercertificate.org. Their wording is > >> identical except for the preamble. > > > You can't change the text of a license and call it the same thing, > > which is why that wording is there (same wording is in the GPL), so > > don't think that by pointing at the one in the kernel source tree > > that changes anything... > > Sure, the text shouldn't be changed without changing the name. I guess > that's common sense, because otherwise it would be confusing. > > > And I would _strongly_ not recomment changing the wording without > > consulting with a license lawyer, you can mess things up really > > quickly by changing stuff. > > So the DCO was devised by a license lawyer? It was created with one, but that was not the only contributor of it. > TBH, I find it less than optimal. It is an enumeration with all its > items at equal level, but its meaning is "I certify ((a || b || c) && > d)". That is, structure doesn't follow contents there, and at first > glance the "or" (or its absence) at the end of each item can be easily > missed. See, you have to be careful and read the whole thing, words can be tricky :) good luck! greg k-h
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Thu, Oct 27, 2016 at 10:11:45AM -0400, Rich Freeman wrote: > On Thu, Oct 27, 2016 at 9:29 AM, Greg KH wrote: > > > > You can't change the text of a license and call it the same thing, > > So is the objection mainly to calling it a "Developer Certificate of Origin?" That's one objection of mine, yes. The other being you can't just take almost all of the original text and still call it the same thing, when it obviously isn't, and the document says you can't do that :) > I'd think that the title of a legal document falls more under > trademark law than copyright law. That is why the FSF publishes the > "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC > LICENSE." The former has far more trademark protection than the > latter. Do you see that term trademarked anywhere? I will go file for one if you really insist on it, but really, think this through please. > > which > > is why that wording is there (same wording is in the GPL), so don't > > think that by pointing at the one in the kernel source tree that changes > > anything... > > The Linux Foundation published a version of their DCO under the GPL, > which we would of course abide by. The fact that they published it > elsewhere with a different license doesn't mean that we can't re-use > the version published under the GPL. How well does "plain text" work under the GPL? Go on, I've been down that path before, it's well-worn, we'll be here when you get back... :) > If we aren't changing anything that does raise the question of why not > just use the Linux DCO, v1.1 or whatever it is at, incorporated by > reference. I do think we have the legal right to fork it since it was > effectively published by the Linux Foundation under the GPL, but that > doesn't require us to fork it. Please just use the one as-published. thanks, greg k-h
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
> On Thu, 27 Oct 2016, Greg KH wrote: >> Also, I wouldn't completely exclude that we need to change the >> wording at some later point. Therefore, we may indeed consider >> taking the DCO from the Linux source tree which is distributed >> under the GPL-2, instead of the non-free version ("changing it is >> not allowed") from developercertificate.org. Their wording is >> identical except for the preamble. > You can't change the text of a license and call it the same thing, > which is why that wording is there (same wording is in the GPL), so > don't think that by pointing at the one in the kernel source tree > that changes anything... Sure, the text shouldn't be changed without changing the name. I guess that's common sense, because otherwise it would be confusing. > And I would _strongly_ not recomment changing the wording without > consulting with a license lawyer, you can mess things up really > quickly by changing stuff. So the DCO was devised by a license lawyer? TBH, I find it less than optimal. It is an enumeration with all its items at equal level, but its meaning is "I certify ((a || b || c) && d)". That is, structure doesn't follow contents there, and at first glance the "or" (or its absence) at the end of each item can be easily missed. Ulrich pgpGzZCjv_WHi.pgp Description: PGP signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
> Therefore, we may indeed consider taking the DCO from the Linux source > tree which is distributed under the GPL-2 I highly doubt that the DCO in the readme is licensed under GPL-2. There is no readme/header, or other indicator stating this. Not everything in the linux repository falls under GPL-2. Thus, we simply blatantly violate the distribution terms: »Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.« Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Thu, Oct 27, 2016 at 9:29 AM, Greg KH wrote: > > You can't change the text of a license and call it the same thing, So is the objection mainly to calling it a "Developer Certificate of Origin?" I'd think that the title of a legal document falls more under trademark law than copyright law. That is why the FSF publishes the "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC LICENSE." The former has far more trademark protection than the latter. > which > is why that wording is there (same wording is in the GPL), so don't > think that by pointing at the one in the kernel source tree that changes > anything... The Linux Foundation published a version of their DCO under the GPL, which we would of course abide by. The fact that they published it elsewhere with a different license doesn't mean that we can't re-use the version published under the GPL. If the FSF published the GPL under the GPL then people would be free to redistribute modified versions of it as well. I don't think they would disagree with that. > And I would _strongly_ not recomment changing the wording without > consulting with a license lawyer, you can mess things up really quickly > by changing stuff. No argument there. I don't think we're actually changing anything at the moment. If we aren't changing anything that does raise the question of why not just use the Linux DCO, v1.1 or whatever it is at, incorporated by reference. I do think we have the legal right to fork it since it was effectively published by the Linux Foundation under the GPL, but that doesn't require us to fork it. -- Rich
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Sat, Oct 22, 2016 at 06:47:04PM +0200, Ulrich Mueller wrote: > > On Sat, 22 Oct 2016, Greg KH wrote: > > > On Wed, Oct 19, 2016 at 09:19:36AM -0400, Rich Freeman wrote: > >> This is from the last policy draft: > >> https://dev.gentoo.org/~rich0/copyrightpolicy.xml > > > Why redraft the already-useful DCO that is out there for you to use > > as-is: > > http://developercertificate.org/ > > > As you copied the text, be sure to give proper reference to who owns > > the copyright of that text please, you just can't rename it and > > claim it as your own :) > > In fact, Rich *does* give credit to Linux: > "The DCO is based on the > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches > Linux Kernel DCO" Credit is nice, but you have to remember copyright issues :) > Also, I wouldn't completely exclude that we need to change the wording > at some later point. Therefore, we may indeed consider taking the DCO > from the Linux source tree which is distributed under the GPL-2, > instead of the non-free version ("changing it is not allowed") from > developercertificate.org. Their wording is identical except for the > preamble. You can't change the text of a license and call it the same thing, which is why that wording is there (same wording is in the GPL), so don't think that by pointing at the one in the kernel source tree that changes anything... And I would _strongly_ not recomment changing the wording without consulting with a license lawyer, you can mess things up really quickly by changing stuff. Again, just point to the one we have, use the web site (which better not go away), and copy it locally if you feel it somehow will. thanks, greg k-h
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/26/2016 04:02 AM, Rich Freeman wrote: > I did suggest that we probably should ban this header until we > actually have a DCO because it blurs the lines. However, it isn't Makes sense, at least strongly discourage, although it likely isn't too difficult to do a full ban on git push > really inferring something that isn't true right now because we don't > assign any legal meaning to the header right now. The bigger concern > is that it blurs the lines after we have a DCO because people can > argue the use of the header was accidental or meant something else. This comes back to the next part, and instituting a clear timeline > > Whether or not we proactively ban the header, it would probably make > sense that if we do institute a new copyright policy including a DCO > that we ask all devs to explicitly ack the policy and the meaning of > the signed-off-by header somehow (maybe issue a gpg signed statement > from a template). It could also be made a part of the ebuild quiz or > such so that all new devs ack it. Exactly (although I'm pleading for people to stop talking about "gpg signed".. thats nonsense :) OpenPGP ftw) > > I don't think we need to go nuts with it. Simply getting everybody to > ack the policy makes it unambiguous that people understand what the > header means. +1 > > But, new policy or not the DCO really represents a practice that we > should all be doing already. Nobody should be sticking code in a > Gentoo repository without ensuring the licenses are compatible and so > on. The DCO just represents a best practice that didn't exist when > Gentoo started and which most projects now embrace in some form. It > isn't that we didn't care about copyright in the past, we just care > enough to be a little more formal about it in the future. > +1 >> > But this doesn't change the fact there is a desire to communicate other >> > properties of commits, like the audit trail for QA purposes. > Sure. The repository should always make it clear who made each > commit, when, and why (with appropriate bug x-refs and so on). > Ideally it should somehow capture both who authored the code and who > put it into the repository. I think for the most part we're already > doing all of this, but I'm sure there is room for improvement (having > a bug header in the default repoman commit template probably wouldn't > hurt - then they all look the same and you can always delete it or > leave it blank if it doesn't apply). Quality of commit messages certainly leaves something to be desired from time to time, and actually having said trail of discussion on bugs.g.o -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Tue, Oct 25, 2016 at 9:39 PM, Kent Fredric wrote: > > Under this interpretation, developers using this header to add other > peoples work to tree is making our use of DCO pointless. > > Because DCO has to be the person who *authored* the commit, not the > person who merely added it to tree. That actually isn't true. Read the DCO. Clauses b/c are designed specifically for cases where the committer isn't the author. It is apparently good enough for the Linux Foundation. They don't require any direct interaction with the author of code to accept it into the kernel. They merely require that whoever submits the code makes the certification that they've done their due diligence. > > And Pram should stop adding it everywhere post-haste, because its > inferring things that aren't true. > I did suggest that we probably should ban this header until we actually have a DCO because it blurs the lines. However, it isn't really inferring something that isn't true right now because we don't assign any legal meaning to the header right now. The bigger concern is that it blurs the lines after we have a DCO because people can argue the use of the header was accidental or meant something else. Whether or not we proactively ban the header, it would probably make sense that if we do institute a new copyright policy including a DCO that we ask all devs to explicitly ack the policy and the meaning of the signed-off-by header somehow (maybe issue a gpg signed statement from a template). It could also be made a part of the ebuild quiz or such so that all new devs ack it. I don't think we need to go nuts with it. Simply getting everybody to ack the policy makes it unambiguous that people understand what the header means. But, new policy or not the DCO really represents a practice that we should all be doing already. Nobody should be sticking code in a Gentoo repository without ensuring the licenses are compatible and so on. The DCO just represents a best practice that didn't exist when Gentoo started and which most projects now embrace in some form. It isn't that we didn't care about copyright in the past, we just care enough to be a little more formal about it in the future. > But this doesn't change the fact there is a desire to communicate other > properties of commits, like the audit trail for QA purposes. Sure. The repository should always make it clear who made each commit, when, and why (with appropriate bug x-refs and so on). Ideally it should somehow capture both who authored the code and who put it into the repository. I think for the most part we're already doing all of this, but I'm sure there is room for improvement (having a bug header in the default repoman commit template probably wouldn't hurt - then they all look the same and you can always delete it or leave it blank if it doesn't apply). -- Rich
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Mon, 24 Oct 2016 07:45:56 -0400 Rich Freeman wrote: > I don't think we need a git header for the purpose of saying that > something looks good to somebody else. If you commit something and it > doesn't work, we'll ask you to stop doing it. If you keep doing it > we'll take away your commit access. This is purely an internal > problem. The problem is that the COMMITTER and AUTHOR headers don't actually reflect the "I tested it and made sure its OK" metadata. If for example, a commit made to Gentoo was replicated to another repository by cherry-pick, the default mechanic would result in COMMITTER changing to the person who performed the cherry-pick. Thus, it makes the assumption that everyone who performed a COMMIT action or an AUTHOR action verified the nature of the commit in some manner. However, the AUTHOR is the least qualified to verify the commit as "Good". and the COMMITTER value changes arbitrarily if you try to cherry-pick or rebase the commit sequence. And people who rebase commit sequences are typically not firing up review engines for every commit they rebased. Granted, this is not a very common problem in Gentoo. But IME, this is the sort of use-case that the header is useful for. If we deem this header useless, then we should probably consider dropping the Portage Version and Repoman Flags headers that repoman adds. Because they're also made entirely irrelevant in very short times, because it only indicates "Authored with", it doesn't indicate anything that happened since then. > The purpose of a DCO is to withstand external scrutiny. It helps > protect Gentoo in the event that somebody else's copyrighted code > makes it into the distro. The audience for a signed-off-by header > isn't Comrel or QA, but rather a court of law. It makes it harder to > contribute something to Gentoo and then argue that you didn't intend > for Gentoo to redistribute it under the GPL, or that now that you've > had a falling out you'd prefer that Gentoo remove all your past > contributions. > > However, it has absolutely no meaning at all if it isn't 100% clear > what is being signed. And if we have a long history of people adding > the header when it doesn't mean anything legally then it will probably > make it harder to argue that it suddenly means something when the > policy changes. > > For example, suppose we institute a DCO tomorrow. Then zlg ragequits > in 2 years and claims he never gave us permission to redistribute his > code under the GPL. We point to his signed-off-by headers but he says > he never heard of the DCO policy and that it was just some default > setting in his config, and that he was adding the headers long before > the policy went into effect. I don't think it would stick but it > really isn't an out we want to give people. IMO infra should reject > commits with this header until we have a DCO, and then it should > reject commits without this header. Alternatively, we could skip the > first part but require all existing devs to ack the new copyright > policy whenever it happens. Under this interpretation, developers using this header to add other peoples work to tree is making our use of DCO pointless. Because DCO has to be the person who *authored* the commit, not the person who merely added it to tree. And Pram should stop adding it everywhere post-haste, because its inferring things that aren't true. But this doesn't change the fact there is a desire to communicate other properties of commits, like the audit trail for QA purposes. It just means we have to find some other way of doing this which is standard, but the stock git commands lack any such mechanism. pgpocxPgRq2WX.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Mon, Oct 24, 2016 at 3:21 AM, Daniel Campbell (zlg) wrote: > > On October 23, 2016 11:29:49 PM PDT, "Michał Górny" wrote: >>Dnia 24 października 2016 07:32:26 CEST, Daniel Campbell >> napisał(a): >>>On 10/19/2016 02:10 AM, Ulrich Mueller wrote: Maybe I have missed something, but why would one use --signoff for a Gentoo commit? For Linux (the kernel), the meaning of the line is that the contributor certifies the DCO (Developer's Certificate of Origin) >>>[1]. As we don't have a Gentoo DCO, it is not at all clear to me what the meaning of a Signed-off-by: line would be in the context of the >>>gentoo tree. Even worse, I see commits having Signed-off-by: lines with obvious pseudonyms instead of a real name, which would be meaningless even >>if one would say that the Linux rules apply. (Also, we have the rule >>>that real names must be provided for all developers, with no exceptions >>to be made for people doing copyrightable work [2].) [1] >>>http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428 [2] >>>https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F >>>The way I understood "signed off by" for Gentoo is "I am a developer >>>who >>>looked at the code and tested it, confirming it works on my system". >>If >>>an AT signs off, they are certifying that it passes their test muster. >>> >>>It's a more formal "looks good to me", and provides a point of >>>accountability if the commit _isn't_ up to par. >> >>How about Gentoo developers stopping to reuse things that have >>well-defined meaning for something completely different? > > I did say "to my understanding". I wasn't aware of DCOs. Regardless, > practices and workflows differ between projects, and it doesn't surprise me > to see projects that use the same words differently. Not that we should, of > course. What would you call what I decribed, though; Acked? I don't think we need a git header for the purpose of saying that something looks good to somebody else. If you commit something and it doesn't work, we'll ask you to stop doing it. If you keep doing it we'll take away your commit access. This is purely an internal problem. The purpose of a DCO is to withstand external scrutiny. It helps protect Gentoo in the event that somebody else's copyrighted code makes it into the distro. The audience for a signed-off-by header isn't Comrel or QA, but rather a court of law. It makes it harder to contribute something to Gentoo and then argue that you didn't intend for Gentoo to redistribute it under the GPL, or that now that you've had a falling out you'd prefer that Gentoo remove all your past contributions. However, it has absolutely no meaning at all if it isn't 100% clear what is being signed. And if we have a long history of people adding the header when it doesn't mean anything legally then it will probably make it harder to argue that it suddenly means something when the policy changes. For example, suppose we institute a DCO tomorrow. Then zlg ragequits in 2 years and claims he never gave us permission to redistribute his code under the GPL. We point to his signed-off-by headers but he says he never heard of the DCO policy and that it was just some default setting in his config, and that he was adding the headers long before the policy went into effect. I don't think it would stick but it really isn't an out we want to give people. IMO infra should reject commits with this header until we have a DCO, and then it should reject commits without this header. Alternatively, we could skip the first part but require all existing devs to ack the new copyright policy whenever it happens. -- Rich
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/24/2016 09:21 AM, Daniel Campbell (zlg) wrote: > What would you call what I decribed, though; Acked? Acked-By and/or Reviewed-By (although we don't have a specific reviewer's statement in Gentoo (yet?)) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On October 23, 2016 11:29:49 PM PDT, "Michał Górny" wrote: >Dnia 24 października 2016 07:32:26 CEST, Daniel Campbell > napisał(a): >>On 10/19/2016 02:10 AM, Ulrich Mueller wrote: On Wed, 19 Oct 2016, Kent Fredric wrote: >>> On Tue, 18 Oct 2016 21:45:05 -0500 Matthew Thode wrote: >>> > Does pram allow you to pass options to git > am (signedoffby for instance)? >>> It doesn't presently allow arbitrary arguments, and it would probably be wise to avoid need for such arguments and prefer convention over configuration, given what this is. >>> --signoff is already a default: >>> >>https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71 >>> >>> Maybe I have missed something, but why would one use --signoff for >>> a Gentoo commit? >>> >>> For Linux (the kernel), the meaning of the line is that the >>> contributor certifies the DCO (Developer's Certificate of Origin) >>[1]. >>> As we don't have a Gentoo DCO, it is not at all clear to me what the >>> meaning of a Signed-off-by: line would be in the context of the >>gentoo >>> tree. >>> >>> Even worse, I see commits having Signed-off-by: lines with obvious >>> pseudonyms instead of a real name, which would be meaningless even >if >>> one would say that the Linux rules apply. (Also, we have the rule >>that >>> real names must be provided for all developers, with no exceptions >to >>> be made for people doing copyrightable work [2].) >>> >>> Ulrich >>> >>> [1] >>http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428 >>> [2] >>https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F >>> >>The way I understood "signed off by" for Gentoo is "I am a developer >>who >>looked at the code and tested it, confirming it works on my system". >If >>an AT signs off, they are certifying that it passes their test muster. >> >>It's a more formal "looks good to me", and provides a point of >>accountability if the commit _isn't_ up to par. > >How about Gentoo developers stopping to reuse things that have >well-defined meaning for something completely different? I did say "to my understanding". I wasn't aware of DCOs. Regardless, practices and workflows differ between projects, and it doesn't surprise me to see projects that use the same words differently. Not that we should, of course. What would you call what I decribed, though; Acked? - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6 bGdAZ2VudG9vLm9yZz4FAlgNtlQACgkQASQOlFA54XDmhw/9HbEDo60eZp38AUMf TgCnj8fYka65Pc9CjLBpJAcvekM2oRcSHB61FdAy8tqIVb7Zx8IvIXNXseOc9sP4 0qNSy89gOKkNRIPx/DC8JFVlmK6YoD5ezZ05tKdzFwcdBvHcJWhKfbO2R2f6L/g5 woLZb4qgxQdFNwOykDy2Ux83W075hFbHaAw9zwpVKAb9LvtMfiJJ2AYEecmnOZDx uVVnkxMrOpAKABhcUqc3d8MnB2NCPwZogL3Z+71duy3puU+71Y338w64vrXDioBY 4pPVIrXk4Ifa799xjCj+Wr2sWYzgHqdJe/cReYZXjRMRzxbvLiZo1PWLejMWgczk CRX0lh6o0cohDxX8oEMiY3s3COqQvD928FzppGkW+8+XQaqXE64VEyHszMuILPL3 cLBbRt39ujmSPJUp/5mX3yUA761QcvRv4wPaDAf81NYllepLoYh2IL9j+5Iqfrf4 QNm/bUeuwxnvLZOMNGTyih/5w2GvhKhLunp170Lm4LGf6BQoEw60ZYot6OlvKFLF Th8oaacTc9acVa7K2lDlH+2ARsqFvfwQgEjGaLczfhFXi8lzIckgtb7Shn1UjEB5 u/7AwgGmO0rC3Mt9GXL7P5xYgWInNxEeyNP+O0d7Lu5CnBsKI9fUvoYnGZblSAWn yt44aBJYOgIzLklGfuQm6xhgdDc= =eesR -END PGP SIGNATURE-
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Mon, 24 Oct 2016 08:29:49 +0200 Michał Górny wrote: > How about Gentoo developers stopping to reuse things that have well-defined > meaning for something completely different? Patching the git tools to have a simple-to-use way to indicate the equivalent metadata welcome ... But like, you're either going to need to patch a lot of things in non-standard ways, or make said feature only possible under repoman ( which makes application of said feature impossible to use as part of a git workflow, which makes using git pointless ) Its doable for Pram, but standardizing the feature across gentoo is hard. Just see how consistent we're using "and we have a bug somewhere" for how not having defacto tools changes how people (fail to) achieve consistency. pgpFGn4s7RmDo.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
Dnia 24 października 2016 07:32:26 CEST, Daniel Campbell napisał(a): >On 10/19/2016 02:10 AM, Ulrich Mueller wrote: >>> On Wed, 19 Oct 2016, Kent Fredric wrote: >> >>> On Tue, 18 Oct 2016 21:45:05 -0500 >>> Matthew Thode wrote: >> Does pram allow you to pass options to git am (signedoffby for instance)? >> >>> It doesn't presently allow arbitrary arguments, and it would >>> probably be wise to avoid need for such arguments and prefer >>> convention over configuration, given what this is. >> >>> --signoff is already a default: >> >>> >https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71 >> >> Maybe I have missed something, but why would one use --signoff for >> a Gentoo commit? >> >> For Linux (the kernel), the meaning of the line is that the >> contributor certifies the DCO (Developer's Certificate of Origin) >[1]. >> As we don't have a Gentoo DCO, it is not at all clear to me what the >> meaning of a Signed-off-by: line would be in the context of the >gentoo >> tree. >> >> Even worse, I see commits having Signed-off-by: lines with obvious >> pseudonyms instead of a real name, which would be meaningless even if >> one would say that the Linux rules apply. (Also, we have the rule >that >> real names must be provided for all developers, with no exceptions to >> be made for people doing copyrightable work [2].) >> >> Ulrich >> >> [1] >http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428 >> [2] >https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F >> >The way I understood "signed off by" for Gentoo is "I am a developer >who >looked at the code and tested it, confirming it works on my system". If >an AT signs off, they are certifying that it passes their test muster. > >It's a more formal "looks good to me", and provides a point of >accountability if the commit _isn't_ up to par. How about Gentoo developers stopping to reuse things that have well-defined meaning for something completely different? -- Best regards, Michał Górny (by phone)
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/19/2016 02:10 AM, Ulrich Mueller wrote: >> On Wed, 19 Oct 2016, Kent Fredric wrote: > >> On Tue, 18 Oct 2016 21:45:05 -0500 >> Matthew Thode wrote: > >>> Does pram allow you to pass options to git >>> am (signedoffby for instance)? > >> It doesn't presently allow arbitrary arguments, and it would >> probably be wise to avoid need for such arguments and prefer >> convention over configuration, given what this is. > >> --signoff is already a default: > >> https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71 > > Maybe I have missed something, but why would one use --signoff for > a Gentoo commit? > > For Linux (the kernel), the meaning of the line is that the > contributor certifies the DCO (Developer's Certificate of Origin) [1]. > As we don't have a Gentoo DCO, it is not at all clear to me what the > meaning of a Signed-off-by: line would be in the context of the gentoo > tree. > > Even worse, I see commits having Signed-off-by: lines with obvious > pseudonyms instead of a real name, which would be meaningless even if > one would say that the Linux rules apply. (Also, we have the rule that > real names must be provided for all developers, with no exceptions to > be made for people doing copyrightable work [2].) > > Ulrich > > [1] > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428 > [2] > https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F > The way I understood "signed off by" for Gentoo is "I am a developer who looked at the code and tested it, confirming it works on my system". If an AT signs off, they are certifying that it passes their test muster. It's a more formal "looks good to me", and provides a point of accountability if the commit _isn't_ up to par. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Sat, Oct 22, 2016 at 10:47 AM, Greg KH wrote: > On Wed, Oct 19, 2016 at 09:19:36AM -0400, Rich Freeman wrote: >> >> The last draft DCO was: >> Gentoo DCO 1.0 By making a contribution to this project, I certify >> that: (a) The contribution was created in whole or in part by me and I >> have the right to submit it under the open source license indicated in >> the file; or (b) The contribution is based upon previous work that, to >> the best of my knowledge, is covered under an appropriate open source >> license and I have the right under that license to submit that work >> with modifications, whether created in whole or in part by me, under >> the same open source license (unless I am permitted to submit under a >> different license), as indicated in the file; or (c) The contribution >> was provided directly to me by some other person who certified (a), >> (b) or (c) and I have not modified it. (d) I understand and agree that >> this project and the contribution are public and that a record of the >> contribution (including all personal information I submit with it, >> including my sign-off) is maintained indefinitely and may be >> redistributed consistent with this project or the open source >> license(s) involved. >> >> This is from the last policy draft: >> https://dev.gentoo.org/~rich0/copyrightpolicy.xml > > Why redraft the already-useful DCO that is out there for you to use > as-is: > http://developercertificate.org/ To be honest I don't remember. The last time I touched it was years ago and maybe there was a reason to fork it at the time, but I can't see a reason for it now. > > As you copied the text, be sure to give proper reference to who owns the > copyright of that text please, you just can't rename it and claim it as > your own :) > Makes sense. I'd suggest copying it into the policy and attributing it vs just incorporating it by reference, since the original might go away (though we've already demonstrated that our own guidexml has not lasted as long as that hosted text file). -- Rich
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
> On Sat, 22 Oct 2016, Greg KH wrote: > On Wed, Oct 19, 2016 at 09:19:36AM -0400, Rich Freeman wrote: >> This is from the last policy draft: >> https://dev.gentoo.org/~rich0/copyrightpolicy.xml > Why redraft the already-useful DCO that is out there for you to use > as-is: > http://developercertificate.org/ > As you copied the text, be sure to give proper reference to who owns > the copyright of that text please, you just can't rename it and > claim it as your own :) In fact, Rich *does* give credit to Linux: "The DCO is based on the http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches Linux Kernel DCO" Also, I wouldn't completely exclude that we need to change the wording at some later point. Therefore, we may indeed consider taking the DCO from the Linux source tree which is distributed under the GPL-2, instead of the non-free version ("changing it is not allowed") from developercertificate.org. Their wording is identical except for the preamble. Ulrich pgpgsX19_nXhZ.pgp Description: PGP signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Wed, Oct 19, 2016 at 09:19:36AM -0400, Rich Freeman wrote: > On Wed, Oct 19, 2016 at 8:32 AM, Kent Fredric wrote: > > > > So if this commit was to get teleported to a different repo, > > --signoff by would be preserved, as an intermediate between these two. > > > > So I think the intent for this is "X reviewed these changes for Gentoo > > and takes responsibility for them" > > > > what text you use to convey that is irrelevant, as long as its used > > consistently and everyone understands what the text means. > > > > Actually, the text matters a great deal, which is why projects that > care about copyright tend to have an explicit DCO. One for Gentoo was > in the works but has stalled somewhat (to be fair, it was stalled > originally because we were waiting for git to come along). It > probably makes sense to at least get that into effect even if we don't > have a long-term strategy around copyright attribution and so on. > > The last draft DCO was: > Gentoo DCO 1.0 By making a contribution to this project, I certify > that: (a) The contribution was created in whole or in part by me and I > have the right to submit it under the open source license indicated in > the file; or (b) The contribution is based upon previous work that, to > the best of my knowledge, is covered under an appropriate open source > license and I have the right under that license to submit that work > with modifications, whether created in whole or in part by me, under > the same open source license (unless I am permitted to submit under a > different license), as indicated in the file; or (c) The contribution > was provided directly to me by some other person who certified (a), > (b) or (c) and I have not modified it. (d) I understand and agree that > this project and the contribution are public and that a record of the > contribution (including all personal information I submit with it, > including my sign-off) is maintained indefinitely and may be > redistributed consistent with this project or the open source > license(s) involved. > > This is from the last policy draft: > https://dev.gentoo.org/~rich0/copyrightpolicy.xml Why redraft the already-useful DCO that is out there for you to use as-is: http://developercertificate.org/ As you copied the text, be sure to give proper reference to who owns the copyright of that text please, you just can't rename it and claim it as your own :) thanks, greg k-h
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
El mar, 18-10-2016 a las 23:13 +0200, Patrice Clement escribió: > Hello fellow Gentoo developers and subscribers of the gentoo-dev > mailing list, > > [...] Thanks a lot for your work! But, is there any place (an official wiki page from the project taking care of github mirror work) where all this information could be stored? Or, at least, a simple guide about what is the preferred way to introduce a PR in main tree for people that are not used (like me) to work with github? That would be really nice :) Best regards!
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Wed, Oct 19, 2016 at 8:32 AM, Kent Fredric wrote: > > So if this commit was to get teleported to a different repo, > --signoff by would be preserved, as an intermediate between these two. > > So I think the intent for this is "X reviewed these changes for Gentoo > and takes responsibility for them" > > what text you use to convey that is irrelevant, as long as its used > consistently and everyone understands what the text means. > Actually, the text matters a great deal, which is why projects that care about copyright tend to have an explicit DCO. One for Gentoo was in the works but has stalled somewhat (to be fair, it was stalled originally because we were waiting for git to come along). It probably makes sense to at least get that into effect even if we don't have a long-term strategy around copyright attribution and so on. The last draft DCO was: Gentoo DCO 1.0 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. This is from the last policy draft: https://dev.gentoo.org/~rich0/copyrightpolicy.xml (And of course you get to read the raw xml these days...) The main issue with the overall copyright policy was the issue with tracking authorship and who goes on the copyright line. -- Rich
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Wed, 19 Oct 2016 14:15:11 +0200 Kristian Fiskerstrand wrote: > > > > Personally I use it as 'I sign off on the Author's work'. I suppose the > > commit itself is good enough for this but I personally prefer verbosity. > > It also calls out that it wasn't my work. > > > > This sounds more like a reviewed by or acked by? I think the important use-case here is to understand why you can't rely on other headers. The beauty of Signed-Off-By is if you cherry-pick a commit with it, its preserved. Default behaviour: - Author is preserved from first committer - Committer is changed every time the commit itself is rebased, cherry-picked, etc. So if this commit was to get teleported to a different repo, --signoff by would be preserved, as an intermediate between these two. So I think the intent for this is "X reviewed these changes for Gentoo and takes responsibility for them" what text you use to convey that is irrelevant, as long as its used consistently and everyone understands what the text means. git help commmit, emphasis added: > Add Signed-off-by line by the committer at the end of the commit log message. > ***The meaning of a signoff depends on the project***, but it typically > certifies that committer has the rights to submit this work under the same > license and agrees to a Developer Certificate of Origin > (see http://developercertificate.org/ for more information). And I think people get hung up too much on the second half of that statement. Sure, we could use some other header, but this one is standard and part of default git tooling. So its at least practical. pgpnB6tRp5481.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Wed, Oct 19, 2016 at 2:10 AM, Ulrich Mueller wrote: >> On Wed, 19 Oct 2016, Kent Fredric wrote: > >> On Tue, 18 Oct 2016 21:45:05 -0500 >> Matthew Thode wrote: > >>> Does pram allow you to pass options to git >>> am (signedoffby for instance)? > >> It doesn't presently allow arbitrary arguments, and it would >> probably be wise to avoid need for such arguments and prefer >> convention over configuration, given what this is. > >> --signoff is already a default: > >> https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71 > > Maybe I have missed something, but why would one use --signoff for > a Gentoo commit? > > For Linux (the kernel), the meaning of the line is that the > contributor certifies the DCO (Developer's Certificate of Origin) [1]. > As we don't have a Gentoo DCO, it is not at all clear to me what the > meaning of a Signed-off-by: line would be in the context of the gentoo > tree. > > Even worse, I see commits having Signed-off-by: lines with obvious > pseudonyms instead of a real name, which would be meaningless even if > one would say that the Linux rules apply. (Also, we have the rule that > real names must be provided for all developers, with no exceptions to > be made for people doing copyrightable work [2].) This is probably worthy of a separate thread. But I completely agree: it's meaningless. Mesa, the project I work on professionally, has the same cargo-culted Signed-off-by with patch reviewers even pointing out lack of (still meaningless!) S-o-b. To all: Signed-off-by doesn't mean anything without a Developer Certificate of Origin. Until a time when Gentoo has one, please stop putting it on your commits.
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/19/2016 07:15 AM, Kristian Fiskerstrand wrote: > On 10/19/2016 02:13 PM, Matthew Thode wrote: >> On 10/19/2016 04:10 AM, Ulrich Mueller wrote: >>> Maybe I have missed something, but why would one use --signoff for >>> a Gentoo commit? >> >> Personally I use it as 'I sign off on the Author's work'. I suppose the >> commit itself is good enough for this but I personally prefer verbosity. >> It also calls out that it wasn't my work. >> > > This sounds more like a reviewed by or acked by? > > Yep, but do either of those have a simple switch I can use (-s)? :P -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/19/2016 02:13 PM, Matthew Thode wrote: > On 10/19/2016 04:10 AM, Ulrich Mueller wrote: >> Maybe I have missed something, but why would one use --signoff for >> a Gentoo commit? > > Personally I use it as 'I sign off on the Author's work'. I suppose the > commit itself is good enough for this but I personally prefer verbosity. > It also calls out that it wasn't my work. > This sounds more like a reviewed by or acked by? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/19/2016 04:10 AM, Ulrich Mueller wrote: > Maybe I have missed something, but why would one use --signoff for > a Gentoo commit? Personally I use it as 'I sign off on the Author's work'. I suppose the commit itself is good enough for this but I personally prefer verbosity. It also calls out that it wasn't my work. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
> On Wed, 19 Oct 2016, Kent Fredric wrote: > On Tue, 18 Oct 2016 21:45:05 -0500 > Matthew Thode wrote: >> Does pram allow you to pass options to git >> am (signedoffby for instance)? > It doesn't presently allow arbitrary arguments, and it would > probably be wise to avoid need for such arguments and prefer > convention over configuration, given what this is. > --signoff is already a default: > https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71 Maybe I have missed something, but why would one use --signoff for a Gentoo commit? For Linux (the kernel), the meaning of the line is that the contributor certifies the DCO (Developer's Certificate of Origin) [1]. As we don't have a Gentoo DCO, it is not at all clear to me what the meaning of a Signed-off-by: line would be in the context of the gentoo tree. Even worse, I see commits having Signed-off-by: lines with obvious pseudonyms instead of a real name, which would be meaningless even if one would say that the Linux rules apply. (Also, we have the rule that real names must be provided for all developers, with no exceptions to be made for people doing copyrightable work [2].) Ulrich [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428 [2] https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F pgpzn5b7olK3M.pgp Description: PGP signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Tue, 18 Oct 2016 23:13:26 +0200 Patrice Clement wrote: > In the case of Gentoo though, it makes no sense. We should strive for > keeping a clean and linear history. A DAG is what I would call linear history :) Merge commits preserve that structure, git log performs a topological sort on the history DAG, effectively showing it to you as a timeline. Now, topsort is kind of classical, very efficient, algorithm so why should I care doing this sorting manually when git does it faster and better than I would ever do ? Also, if you want to see linear history, why do you use git log --graph ? This seems to me you're inventing your own problems :) > By avoiding merge commits, we make sure the history stay linear with > no parent/child commits all over the place. It leads us to the two > remaining solutions for dealing with PRs in a clean fashion: > cherry-picking and git am. These two solutions really shine at > keeping a sane history. git merge ... git rebase origin/master this kills the merge commit and reparents the commits you merged to the tip of origin/master
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/19/2016 01:00 AM, Robin H. Johnson wrote: > One of the downsides both the git-am and cherry-pick workflows are that > they invalidate or otherwise omit commit signatures. > > git-merge on the other hand does preserve the signature as the original > commit is intact, and the merge commit is where the signature of the > gentoo developer is introduced. > > I agree clean history is valuable, but verifiable attribution may in > fact be more important. > Yes, I don't like this aspect of any workflow that breaks history but I personally feel that for the sake of both 'cleanliness' and ease of use that the git am (or cherry-pick) workflow is best. I could possibly see the possibility of tampering with the patch could be a problem (attribution as you say) but in the end a developer still committed it. Authored-by and Committed-by being different fields I feel the main one infra needs to worry about is Committed-by. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
One of the downsides both the git-am and cherry-pick workflows are that they invalidate or otherwise omit commit signatures. git-merge on the other hand does preserve the signature as the original commit is intact, and the merge commit is where the signature of the gentoo developer is introduced. I agree clean history is valuable, but verifiable attribution may in fact be more important. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: Digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Tue, 18 Oct 2016 21:45:05 -0500 Matthew Thode wrote: > Does pram allow you to pass options to git > am (signedoffby for instance)? It doesn't presently allow arbitrary arguments, and it would probably be wise to avoid need for such arguments and prefer convention over configuration, given what this is. --signoff is already a default: https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71 pgpseI3abq5cg.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
I've been using the curl into git am method for a while now, it's nice to see it's not just me :D Does pram allow you to pass options to git am (signedoffby for instance)? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/18/2016 08:03 PM, Benda Xu wrote: > > This will be an important reference. Please consider adding it into the > wiki after we reach a wider consensus on how to merge pull request on > github. It's been there for a long time: https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Pull_requests_from_developers_and_users (that's the way I prefer to merge pull requests, too).
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
Hi Patrice, Patrice Clement writes: > [...] Very enjoyable write-up. I completely agree with you. This will be an important reference. Please consider adding it into the wiki after we reach a wider consensus on how to merge pull request on github. Benda signature.asc Description: PGP signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
Patrice Clement wrote: > We should strive for keeping a clean and linear history. I agree with you. > Cherry-picking is not my go-to solution as far as I'm concerned. > It requires a bit of setup and is clearly tedious: you must know > in advance the full SHA-1 of commit(s) you want to cherry-pick. git cherry-pick master..pr1234 # picks all commits on pr1234 not on master This is essentially a "manual" rebase of pr1234 onto master. Demo time. Preparations: $ git config --global alias.la 'log --oneline --graph --decorate --all' $ export PAGER=cat Assume the following repo: $ git la * ccbc288 (HEAD, master) d * d33a95b b | * 3e5b52e (pr1234) c | * 6491f93 b2 |/ * 2dfcb95 a $ git cherry-pick master..pr1234 would apply b2 and c onto master: $ git cherry-pick master..pr1234 [master 305532b] b2 1 file changed, 1 insertion(+) create mode 100644 b2 [master d18f1ac] c 1 file changed, 1 insertion(+) create mode 100644 c $ git la * d18f1ac (HEAD, master) c * 305532b b2 * ccbc288 d * d33a95b b | * 3e5b52e (pr1234) c | * 6491f93 b2 |/ * 2dfcb95 a $ If the pr1234 branch has some value once b2 and c are in master then this is a good way to do it, the main drawback IMO that it leaves a repetitive and redundant pr1234 branch behind. Another way would be to simply rebase the pr1234 branch. Disclaimer: I don't know GitHub processes and assumptions, so rebase might suck for this. If noone cares about the PR branches once they have been merged/closed (I got that impression from your mail) then rebase may be a good choice. $ git la * ccbc288 (HEAD, master) d * d33a95b b | * 3e5b52e (pr1234) c | * 6491f93 b2 |/ * 2dfcb95 a $ git rebase master pr1234 First, rewinding head to replay your work on top of it... Applying: b2 Applying: c $ git la * 92417d4 (HEAD, pr1234) c * 385ca8c b2 * ccbc288 (master) d * d33a95b b * 2dfcb95 a $ At this point, pr1234 can be fast-forward merged into master: $ git checkout master Switched to branch 'master' $ git merge --ff-only pr1234 Updating ccbc288..0565e44 Fast-forward b2 | 1 + c | 1 + 2 files changed, 2 insertions(+) create mode 100644 b2 create mode 100644 c $ git la * 0565e44 (HEAD, pr1234, master) c * 0dbfdf8 b2 * ccbc288 d * d33a95b b * 2dfcb95 a $ > You may or may not know about it but a PR can be fetched as a git > am-compatible patch. .. > https://github.com/gentoo/gentoo/pull/1234.patch Didn't know - that's pretty handy! > $ cd /home/patrice/gentoo > $ pram 1234 Nice work! I might have made a git pr alias instead, but pram seems way more flexible than that would be. Finally, while I do agree with you, the one and only reason IMO to live with merge commits is that they implicitly preserve the branching point. For source code that can be useful, but for ebuilds less so. //Peter
[gentoo-dev] Dealing with GitHub Pull Requests the easy way
Hello fellow Gentoo developers and subscribers of the gentoo-dev mailing list, I've been wanting to write this email for a while but for some reason never got round to doing it due to lack of motivation and time. I will be discussing many topics in this email revolving around git essentially. I first want to go over some basic concepts about git and GitHub and why we should be doing things differently if we want to avoid cluttering up our repository with useless stuff. * Background As you know, a little while ago we've migrated the main tree to git, the revision control tool which needs no introduction. A few months after the migration, our repository was mirrored over to GitHub to give the project a bit more exposure to what some developers refers to as "the GitHub generation". The response from the community was extordinary and as a result, a massive number of Pull Requests came our way. We soon then started to lend ourselves to the duty of PR triaging and merging, and started to make what's called in the git world "merge commits". Understanding merge commits requires understanding how GitHub considers a contribution. When a contributor sends a PR via GitHub, he will essentially be making a different branch, start working on it and eventually file it. For those of you familiar with git or who've already filed PRs on GitHub, this is old news. However, there's a number of different way to deal with PRs on the receiving end (us) in order to keep a sane log history (graph actually). When we first started working with git, and GitHub, the tendency was to rely on merge commits to merge contributions back into the main repo. In my opinion, this was, and still is, a bad idea. What's so special about merge commits? * A short walk through merge commits As you may know, merging one branch into another often results in creating a new commit. This commit is called a "merge commit" in git jargon. Let's pick for instance cf4cce36684de5e449ec60bde3421fa0e27bac74. I'm not trying to put the blame on a particular developer, we've all used merge commits at one point or another and I was one of the first! In the log graph, this commit is displayed as such: $ git log --graph --oneline master [snip] * | | cf4cce3 Merge remote-tracking branch 'github/pr/1845' |\ \ \ | * | | abf61de net-im/ejabberd: require https://github.com/gentoo/gentoo/pull/1234.patch Once fetched, using your favourite web crawler, the patch can be directly applied via the git am command onto HEAD of the repository you're dealing with. There's this common idiom for fetching AND applying at patch all at once: $ curl https://github.com/gentoo/gentoo/pull/1234.patch | git am * This is where I'm meant to sell you my solution Ultimately, I've decided to write a tool to leverage this way of fetching PRs and merging them. The tool is called Gentoo-App-Pram and is available in the tree: # emerge Gentoo-App-Pram It is written in Perl, works fairly well and has been used by a fair (growing?) number of developers so far. The tool is CLI-based so you will need to feel at home with the command line. Once emerged, cd into your Gentoo git repo and type `pram' followed by the PR number you wish to merge: $ cd /home/patrice/gentoo $ pram 1234 pram will then fetch the PR as a patch and display it to you in your favourite $EDITOR. At this point, you can make any change to the PR i.e. editing commit message(s), changing code in-line, etc. pram also leverages the "Closes:" header. This header is recognised by GitHub, and Larry the Cow, and will automatically close a PR when parsing it in the body of a commit message. So for instance, the following header will automatically close PR 1234: "Closes: https://github.com/gentoo/gentoo/pull/1234";. You don't need to manually add it as pram will do this for you. After saving and getting out of $EDITOR, pram will ask you whether the PR needs merging by asking a yes/no question. "y" will launch git am and merge the patch whereas "n" will abort the operation and clean it up. That's pretty much it. Make sure to read the man page since there are other options available (pram --man). pram wouldn't have been possible without Kent Fredric's help. He's assisted me in releasing the package on CPAN and contributed a few patches. Kudos to him! To wrap up: - Please stop making merge commits. This strategy is not useful in the case of Gentoo and does more harm than good. - Cherry-pick or git-am external contributions such as PRs. - Better yet, use Gentoo-App-Pram. :-) If you want to contribute to Gentoo-App-Pram, send me a PR on GitHub at https://github.com/monsieurp/Gentoo-App-Pram or file a bug report at https://bugs.gentoo.org and assign it to me. Comments and suggestions welcome. Cheers, -- Patrice Clement Gentoo Linux developer http://www.gentoo.org signature.asc Description: PGP signature