Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
16.02.2015 14:43, Patrick Lauer пишет: On Monday 16 February 2015 06:13:10 Mike Frysinger wrote: On Mon, Feb 16, 2015 at 1:16 AM, Alec Warner anta...@gentoo.org wrote: On Sun, Feb 15, 2015 at 8:05 PM, Mike Frysinger vap...@gentoo.org wrote: On Wed, Dec 31, 2014 at 12:21 AM, Patrick Lauer (patrick) patr...@gentoo.org wrote: patrick 14/12/31 05:21:11 Removed: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml Log: QA: Remove package with invalid copyright you do not go reverting code without actually talking to people. if you feel like a revert is necessary, then file a bug. putting a QA tag at the start of the commit message doesn't give you a pass. Normally I'd side with you on this...but I'm fairly sure repoman doesn't let you commit packages to the tree missing these headers. This leads me to believe you didn't use repoman, or ignored it? feel free to grab the code i originally committed and run `repoman full` yourself. no fatal errors. in fact you can see the generated tags in my commit message. Well, AutoRepoman triggered on it. Testing for fun on a random ebuild: RepoMan scours the neighborhood... ebuild.badheader 1 dev-db/hyperdex/hyperdex-1.6.0-r1.ebuild: Invalid Gentoo Copyright on line: 1 Which again leads me to the question: Why are these checks not properly fatal? (And I really do not like having to repeat myself ...) even then, deleting an ebuild purely due to different copyright is complete bs. anyone who understands copyright knows the situation in Gentoo is completely unenforceable. we have no CLA. this was patrick/QA wasting people's time to check a meaningless box. -mike As others have pointed out, policy is policy. Don't shoot the massager. Since I can't just fix the copyright (that would be more wrong) I opted for the easy way out - remove offending bits. Have fun, Patrick Your logic is almost flawless. Almost, because you forgot the valuable part of our policy - notifying maintainer. If your package will be dropped because you violate QA rules - well, things can happen. But if it will be done silently, i am pretty sure that you will be angry. I would be, definitely. I am not asking for justification of every action, that QA doing by maintainer - that would be totally wrong. Just follow our policy: Serious issue - fix and after that notify maintainer. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
16.02.2015 14:44, Markos Chandras пишет: On 02/16/15 13:31, Andreas K. Huettel wrote: Am Montag 16 Februar 2015, 06:13:10 schrieb Mike Frysinger: even then, deleting an ebuild purely due to different copyright is complete bs. The requirement for Gentoo copyright in the main tree is not optional, but has been policy for a very long time. Just because you've been around forever doesnt mean you can break the rules that everyone else is supposed to follow. I too believe that if you are reverting someone's commit you should at least drop him an email to let him know. How else do you expect him to know he did something wrong? I am a bit worried QA is taking such actions without communicating that with the developer. If you don't let people know they do mistakes, it's likely they will do them again. This is clear violation of our QA policy and AGAIN, patrick is involved. @patrick: vapier claims that he was not aware about your actions. But according to our policy you should notify maintainer. At least in case of serious actions. I am sure that dropping package is a damn serious action. I am not sure how should i proceed. Your work for QA is much appreciated, but, think about this message as a first warning from me as QA team lead to you. Please, be more communicative with your fellow developers. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
Joshua Kinard posted on Tue, 17 Feb 2015 12:46:12 -0500 as excerpted: On 02/16/2015 13:01, Rich Freeman wrote: On Mon, Feb 16, 2015 at 11:02 AM, Joshua Kinard ku...@gentoo.org wrote: On 02/16/2015 09:04, Rich Freeman wrote: Maybe another approach is to just ditch per-file copyrights entirely (which a random perusal suggests is how Linux does things), but that would STILL require stripping the copyright out of these files with all the issues that entails, and limit our ability to borrow license-compatible code. [M]y understanding is the kernel retains per-file copyrights. This is why the kernel is permanently wedded to GPLv2, because some of the contributors owning those copyrights have died and thus can no longer consent to changing to the GPLv3[.] Perhaps I should have worded that better. s/per-file copyrights/per-file copyright notices/ Obviously the content of individual files will always be copyrighted absent a release into the public domain. The Linux kernel just doesn't stick notices on individual files that attempt to identify who owns the copyright on what. Presumably that also means that if they borrow a file from somewhere else they don't care to change the copyright notice that was already there (or somehow they manage to avoid the euthusiasm stirred up by removing said notices). Well, I just sent a patch upstream that adds a new RTC driver to the kernel, and I added copyright to myself and the guy that created the original driver that I based off of to the top of the source file (and its header). So that practice is still used, and akpm recently added it to -mm with no comment on any of the copyright bits, so I must've gotten part that right. It's probably left to the person writing the specific source file(s) on how they want to do copyright, as long as they stick to recognized norms and GPLv2. The kernel's relatively relaxed per-file copyright and license policy is in the context of git and its record of a rather strong explicit per-commit signed-off-by policy. As a result of the strong per-commit signed-off-by policy, they can be and are relatively more relaxed on a per-file policy, since the sign-off policy requires legal responsibility and the authority to grant default-gpl2-only permissions on anything committed in the first place. As such, any file without an explicit license CAN BE ASSUMED to have the GPLv2 license, and copyright CAN BE ASSUMED to remain with the original author (company in the case of a work- for-hire unless otherwise stated), because that's part of the conditions that are agreed to by the explicit signed-off-by. Since gentoo lacks this sort of formal signed-off policy and in fact has yet to move to git where it could be most easily tracked and enforced (let alone such a policy created and formally agreed in the first place), the extent to which the kernel's relatively relaxed per-file policies could apply to gentoo in its current cvs and policy state is rather limited. IOW, the kernel's policy doesn't apply here, except to the extent that we use it as a goal/model to increase the urgency of the switch to git, and once having done so, creating and adopting a similarly strict per-commit- sign-off basic policy context in which to apply a similarly relaxed per- file policy. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Tue, Feb 17, 2015 at 9:19 PM, Duncan 1i5t5.dun...@cox.net wrote: Since gentoo lacks this sort of formal signed-off policy and in fact has yet to move to git where it could be most easily tracked and enforced (let alone such a policy created and formally agreed in the first place), the extent to which the kernel's relatively relaxed per-file policies could apply to gentoo in its current cvs and policy state is rather limited. IOW, the kernel's policy doesn't apply here, except to the extent that we use it as a goal/model to increase the urgency of the switch to git, and once having done so, creating and adopting a similarly strict per-commit- sign-off basic policy context in which to apply a similarly relaxed per- file policy. I was thinking more for after the git migration and we have a DCO. A big part of what was holding me back from pushing more on the new policy is the fact that the bookkeeping looks potentially onerous. If we could simplify things and be compliant and just have a simple DCO and optional FLA, then there isn't a lot holding us back besides git (and maybe we can find a way around that if we're desperate). -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On 02/16/2015 13:01, Rich Freeman wrote: On Mon, Feb 16, 2015 at 11:02 AM, Joshua Kinard ku...@gentoo.org wrote: On 02/16/2015 09:04, Rich Freeman wrote: I do think that moving to a cleaner policy makes a lot of sense. The problem is that doing this sort of thing right potentially involves a lot of work as well. Maybe another approach is to just ditch per-file copyrights entirely (which a random perusal suggests is how Linux does things), but that would STILL require stripping the copyright out of these files with all the issues that entails, and limit our ability to borrow license-compatible code. Focusing on the last paragraph here (but not snipping), my understanding is the kernel retains per-file copyrights. This is why the kernel is permanently wedded to GPLv2, because some of the contributors owning those copyrights have died and thus can no longer consent to changing to the GPLv3 (or any other OSI license, or copyright change). Trying to track down their appropriate heirs, explain the whole situation, and then seek a consent would be a near-impossible undertaking. Hence, permanent GPLv2. Perhaps I should have worded that better. s/per-file copyrights/per-file copyright notices/ Obviously the content of individual files will always be copyrighted absent a release into the public domain. The Linux kernel just doesn't stick notices on individual files that attempt to identify who owns the copyright on what. Presumably that also means that if they borrow a file from somewhere else they don't care to change the copyright notice that was already there (or somehow they manage to avoid the euthusiasm stirred up by removing said notices). Well, I just sent a patch upstream that adds a new RTC driver to the kernel, and I added copyright to myself and the guy that created the original driver that I based off of to the top of the source file (and its header). So that practice is still used, and akpm recently added it to -mm with no comment on any of the copyright bits, so I must've gotten part that right. It's probably left to the person writing the specific source file(s) on how they want to do copyright, as long as they stick to recognized norms and GPLv2. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On 16/02/15 12:58, Mike Frysinger wrote: On 16 Feb 2015 19:43, Patrick Lauer wrote: On Monday 16 February 2015 06:13:10 Mike Frysinger wrote: even then, deleting an ebuild purely due to different copyright is complete bs. anyone who understands copyright knows the situation in Gentoo is completely unenforceable. we have no CLA. this was patrick/QA wasting people's time to check a meaningless box. As others have pointed out, policy is policy. Don't shoot the massager. again, that's bs. nowhere does the policy state silently delete things without talking to anyone, nor does it state ignore common sense, blindly follow the rules, and act how your think the policy states. nothing here was cause for alarm that could possibly have warranted straight up deletion. Since I can't just fix the copyright (that would be more wrong) considering how copyright *actually* works for us, this statement is fairly ludicrous. I opted for the easy way out - remove offending bits. sorry, but you did it wrong. please don't do it again. -mike Can we just have repoman directly fix the entry automatically since in itself is nearly-pointless? Another option is remove that header and just state that all the .ebuild are under $license in a simpler way... lu
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On 02/16/2015 09:04, Rich Freeman wrote: On Mon, Feb 16, 2015 at 7:44 AM, Joshua Kinard ku...@gentoo.org wrote: As far as removing the ebuild goes, that was probably the correct course of action, because we Yanks love to make our legal code as bizzaringly complex as we think we can. Though, the mistaken code is still in CVS in the Attic -- does that itself present any problems that need to be addressed? So, there are a bunch of issues here, but let's just address whether the copyright line was a problem and set aside all the personal/organizational/procedural stuff: 1. We have a clear policy that the copyright line must be exactly foo, and this one wasn't. 2. MAYBE violating that policy could or couldn't cause an issue, but the legalities of that become really messy really fast, so it is better to just follow the policy until it is changed. 3. I don't really see a problem with having the file in the Attic unless somebody asks us to take it down. The file is legally redistributable, after all. A few of the issues I see with having the file in the tree unmodified: 1. It is GPL-2, not GPL-2+, which could create issues with relicensing if we wanted to. If copyright were assigned to the Foundation there would not be an issue with that. Yes, I realize that the current policy is at best ambiguous on that front. However, we're not doing ourselves any favors by switching from an ambiguous but potentially advantageous approach to an unambiguous but disadvantageous approach. 2. It opens the door to lots of other situations like this in the absence of any sane policy for dealing with them. The current policy requires committers to ensure that it is legal to put in the copyright line as the policy dictates, and to keep stuff out of the tree if not. It isn't a great policy, but it is at least workable and obviously being the status quo it is what it is. I do think that moving to a cleaner policy makes a lot of sense. The problem is that doing this sort of thing right potentially involves a lot of work as well. Maybe another approach is to just ditch per-file copyrights entirely (which a random perusal suggests is how Linux does things), but that would STILL require stripping the copyright out of these files with all the issues that entails, and limit our ability to borrow license-compatible code. Focusing on the last paragraph here (but not snipping), my understanding is the kernel retains per-file copyrights. This is why the kernel is permanently wedded to GPLv2, because some of the contributors owning those copyrights have died and thus can no longer consent to changing to the GPLv3 (or any other OSI license, or copyright change). Trying to track down their appropriate heirs, explain the whole situation, and then seek a consent would be a near-impossible undertaking. Hence, permanent GPLv2. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Mon, Feb 16, 2015 at 12:50 PM, Luca Barbato lu_z...@gentoo.org wrote: Can we just have repoman directly fix the entry automatically since in itself is nearly-pointless? That would leave the door open to somebody arguing that the line was changed without their knowledge. Absent some kind of DCO that seems even more legally problematic than the current state, which I wholeheartedly agree isn't ideal. You can at least make an argument that in sticking that header line on their file people are implicitly assigning copyright in jurisdictions that recognize this. Whether that argument would hold up in court is difficult to say. Another option is remove that header and just state that all the .ebuild are under $license in a simpler way... As I said in my other email, that might be a simpler way to go. Of course, does that make it acceptable to strip the copyright notice if it is already there? It seems like this caused a huge stir the last time the topic came up, which makes it possible that we end up with all kinds of random notices in random files which may or may not reflect the actual copyright status of the tree at the moment. The topic that originally raised this issue was the importing of files that already had copyright notices into a Gentoo repository, and the question of what to do with them. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Mon, Feb 16, 2015 at 11:02 AM, Joshua Kinard ku...@gentoo.org wrote: On 02/16/2015 09:04, Rich Freeman wrote: I do think that moving to a cleaner policy makes a lot of sense. The problem is that doing this sort of thing right potentially involves a lot of work as well. Maybe another approach is to just ditch per-file copyrights entirely (which a random perusal suggests is how Linux does things), but that would STILL require stripping the copyright out of these files with all the issues that entails, and limit our ability to borrow license-compatible code. Focusing on the last paragraph here (but not snipping), my understanding is the kernel retains per-file copyrights. This is why the kernel is permanently wedded to GPLv2, because some of the contributors owning those copyrights have died and thus can no longer consent to changing to the GPLv3 (or any other OSI license, or copyright change). Trying to track down their appropriate heirs, explain the whole situation, and then seek a consent would be a near-impossible undertaking. Hence, permanent GPLv2. Perhaps I should have worded that better. s/per-file copyrights/per-file copyright notices/ Obviously the content of individual files will always be copyrighted absent a release into the public domain. The Linux kernel just doesn't stick notices on individual files that attempt to identify who owns the copyright on what. Presumably that also means that if they borrow a file from somewhere else they don't care to change the copyright notice that was already there (or somehow they manage to avoid the euthusiasm stirred up by removing said notices). -- Rich
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
Am Montag 16 Februar 2015, 13:05:54 schrieb Rich Freeman: Another option is remove that header and just state that all the .ebuild are under $license in a simpler way... As I said in my other email, that might be a simpler way to go. Of course, does that make it acceptable to strip the copyright notice if it is already there? It seems like this caused a huge stir the last time the topic came up, which makes it possible that we end up with all kinds of random notices in random files which may or may not reflect the actual copyright status of the tree at the moment. The topic that originally raised this issue was the importing of files that already had copyright notices into a Gentoo repository, and the question of what to do with them. I'm all for writing down new rules to simplify this, since the current state *is* kinda ugly. So here's a simple question: If a file is released under the correct license (which we could require, e.g. as a first line comment / license statement, similar to today's header), why is the copyright owner or the copyright statement even relevant? Can't we just only require the correct license statement and leave all copyright statements as they are in whatever form? (I mean, committing from Germany where only *natural* persons can be entitled to copyright, this is silly anyway...) -- Andreas K. Huettel Gentoo Linux developer perl, office, comrel, council
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Mon, Feb 16, 2015 at 3:13 AM, Mike Frysinger vap...@gentoo.org wrote: On Mon, Feb 16, 2015 at 1:16 AM, Alec Warner anta...@gentoo.org wrote: On Sun, Feb 15, 2015 at 8:05 PM, Mike Frysinger vap...@gentoo.org wrote: On Wed, Dec 31, 2014 at 12:21 AM, Patrick Lauer (patrick) patr...@gentoo.org wrote: patrick 14/12/31 05:21:11 Removed: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml Log: QA: Remove package with invalid copyright you do not go reverting code without actually talking to people. if you feel like a revert is necessary, then file a bug. putting a QA tag at the start of the commit message doesn't give you a pass. Normally I'd side with you on this...but I'm fairly sure repoman doesn't let you commit packages to the tree missing these headers. This leads me to believe you didn't use repoman, or ignored it? feel free to grab the code i originally committed and run `repoman full` yourself. no fatal errors. in fact you can see the generated tags in my commit message. Seems like a bug worth fixing then. even then, deleting an ebuild purely due to different copyright is complete bs. anyone who understands copyright knows the situation in Gentoo is completely unenforceable. we have no CLA. this was patrick/QA wasting people's time to check a meaningless box. Well we agree there, although I doubt anyone will bother fixing it ;) -A -mike
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Mon, Feb 16, 2015 at 1:32 PM, Andreas K. Huettel dilfri...@gentoo.org wrote: Can't we just only require the correct license statement and leave all copyright statements as they are in whatever form? Obviously appealing for its simplicity. But, I can see some issues: 1. What if you want to import multiple code snippets with different copyright notices into the same file? 2. Do we want to retain the option to sue somebody who steals GPL code and uses it contrary to the license? Will inaccurate or absent notices hinder that? 3. What if I as an author want to add myself to the copyright line? When can I do that? 4. What if we borrow a small bit of code from some company, it ends up having the only copyright notice in the entire file, and then they use that as justification for using the entirety of the file (mostly Gentoo work) in a proprietary-licensed work? 5. If we start to accumulate conflicting copyright notices, can we ever trim some out? One of the goals of the policy I drafted was to have somewhat clear rules about what goes on the copyright line, and nobody would ever have their names taken off of it unless their contribution ended up not being in the top 50% or whatever. I was thinking about this and wondering if an automated tool could parse git author headers and auto-generate an up-to-date attribution. For this to work every commit would need to have correct author attribution (so if you borrow FooCo code, you do it in a commit that has an Author: FooCo header and not your own name - signed-off-by would still be yourself). Basically do a git blame, determine author for each line, substituted Gentoo for any authors which are on record as signing an FLA, word count those, then sort descending and accumulate authors until 50% of the lines in the file are accounted for. Sounds like a nice little project. I think the kernel actually attributes authors correctly - I might try running it on their repository. The migrated Gentoo repositories should also work. Something like that could even go into repoman. I think the auto-changing of the copyright notice isn't such a bad thing if it is on the basis of authors recorded by individual committers who are signing DCOs confirming this data is correct. The copyright notice is basically just a summary of the more complete data in the repo. -- Rich
Re: Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On 16 Feb 2015 13:12, Andreas K. Huettel wrote: Am Montag 16 Februar 2015, 07:03:18 schrieb Mike Frysinger: except for two things: * that phrase is meaningless (legally speaking) and has been for a century [1] * the header explicitly stated GPL-2 license So you want to change a longstanding policy rule. Right. How about doing this like everyone else and starting a discussion about it? You know, like, talking to people? again, stop trying to put your words in my mouth and read my other replies. your perception of events intentions is completely wrong. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Mon, Feb 16, 2015 at 7:44 AM, Joshua Kinard ku...@gentoo.org wrote: As far as removing the ebuild goes, that was probably the correct course of action, because we Yanks love to make our legal code as bizzaringly complex as we think we can. Though, the mistaken code is still in CVS in the Attic -- does that itself present any problems that need to be addressed? So, there are a bunch of issues here, but let's just address whether the copyright line was a problem and set aside all the personal/organizational/procedural stuff: 1. We have a clear policy that the copyright line must be exactly foo, and this one wasn't. 2. MAYBE violating that policy could or couldn't cause an issue, but the legalities of that become really messy really fast, so it is better to just follow the policy until it is changed. 3. I don't really see a problem with having the file in the Attic unless somebody asks us to take it down. The file is legally redistributable, after all. A few of the issues I see with having the file in the tree unmodified: 1. It is GPL-2, not GPL-2+, which could create issues with relicensing if we wanted to. If copyright were assigned to the Foundation there would not be an issue with that. Yes, I realize that the current policy is at best ambiguous on that front. However, we're not doing ourselves any favors by switching from an ambiguous but potentially advantageous approach to an unambiguous but disadvantageous approach. 2. It opens the door to lots of other situations like this in the absence of any sane policy for dealing with them. The current policy requires committers to ensure that it is legal to put in the copyright line as the policy dictates, and to keep stuff out of the tree if not. It isn't a great policy, but it is at least workable and obviously being the status quo it is what it is. I do think that moving to a cleaner policy makes a lot of sense. The problem is that doing this sort of thing right potentially involves a lot of work as well. Maybe another approach is to just ditch per-file copyrights entirely (which a random perusal suggests is how Linux does things), but that would STILL require stripping the copyright out of these files with all the issues that entails, and limit our ability to borrow license-compatible code. -- Rich
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On 12/31/2014 06:21 AM, Patrick Lauer (patrick) wrote: patrick 14/12/31 05:21:11 Removed: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml Log: QA: Remove package with invalid copyright Both people made an excellent point for enforcing peer-reviews (that includes vapier), because both commits were wrong. But then again I am pretty sure that both developers involved will be the last ones asking anyone for review. Have fun.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On 02/16/2015 07:12, Andreas K. Huettel wrote: Am Montag 16 Februar 2015, 07:03:18 schrieb Mike Frysinger: except for two things: * that phrase is meaningless (legally speaking) and has been for a century [1] * the header explicitly stated GPL-2 license So you want to change a longstanding policy rule. Right. How about doing this like everyone else and starting a discussion about it? You know, like, talking to people? Just silently committing stuff that goes against standing rules because you disagree with the rules is not the way to go. It's childish and immature. (Remember the ChangeLogs?) Mike stated he made a mistake while making (what I assume to be) multiple changes across a variety of packages. I don't get a sense that he had an intentional desire to break the rules here, so let's not go pointing fingers until we know otherwise. We're human, and humans make mistakes sometimes. If anyone here is not humanwell, then we have a whole different set of problems to discuss. As far as removing the ebuild goes, that was probably the correct course of action, because we Yanks love to make our legal code as bizzaringly complex as we think we can. Though, the mistaken code is still in CVS in the Attic -- does that itself present any problems that need to be addressed? That stated, communication is key and that was one of the parts that appears to have been missed in this instance. We don't have to like each other, but we do need to learn to work around our differences and disagreements for the good of the project. So, lets learn something from this and move along. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Mon, Feb 16, 2015 at 1:16 AM, Alec Warner anta...@gentoo.org wrote: On Sun, Feb 15, 2015 at 8:05 PM, Mike Frysinger vap...@gentoo.org wrote: On Wed, Dec 31, 2014 at 12:21 AM, Patrick Lauer (patrick) patr...@gentoo.org wrote: patrick 14/12/31 05:21:11 Removed: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml Log: QA: Remove package with invalid copyright you do not go reverting code without actually talking to people. if you feel like a revert is necessary, then file a bug. putting a QA tag at the start of the commit message doesn't give you a pass. Normally I'd side with you on this...but I'm fairly sure repoman doesn't let you commit packages to the tree missing these headers. This leads me to believe you didn't use repoman, or ignored it? feel free to grab the code i originally committed and run `repoman full` yourself. no fatal errors. in fact you can see the generated tags in my commit message. even then, deleting an ebuild purely due to different copyright is complete bs. anyone who understands copyright knows the situation in Gentoo is completely unenforceable. we have no CLA. this was patrick/QA wasting people's time to check a meaningless box. -mike
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Mon, Feb 16, 2015 at 1:16 AM, Alec Warner anta...@gentoo.org wrote: even then, deleting an ebuild purely due to different copyright is complete bs. No. Tree policy. -- Andreas K. Huettel Gentoo Linux developer perl, office, comrel, council
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
Am Montag 16 Februar 2015, 06:13:10 schrieb Mike Frysinger: even then, deleting an ebuild purely due to different copyright is complete bs. The requirement for Gentoo copyright in the main tree is not optional, but has been policy for a very long time. Just because you've been around forever doesnt mean you can break the rules that everyone else is supposed to follow. -- Andreas K. Huettel Gentoo Linux developer perl, office, comrel, council
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On 16 Feb 2015 12:31, Andreas K. Huettel wrote: Am Montag 16 Februar 2015, 06:13:10 schrieb Mike Frysinger: even then, deleting an ebuild purely due to different copyright is complete bs. The requirement for Gentoo copyright in the main tree is not optional, but has been policy for a very long time. where exactly did i say i intended for it to stay that way ? i was syncing multiple things that day from CrOS and one update i missed the pointless munging of the header. had Patrick done the reasonable thing (actually talking to me), i could have fixed it fairly quickly. but lets be clear here to illustrate the inane behavior you're attempting to justify. the policy is not it must be Gentoo copyright, but it must have a header that says Gentoo copyright even though there's no legal basis for it. Just because you've been around forever doesnt mean you can break the rules that everyone else is supposed to follow. cut the crap. trying to put words into my mouth doesn't stop making them yours. -mike signature.asc Description: Digital signature
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Mon, Feb 16, 2015 at 6:31 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: Am Montag 16 Februar 2015, 06:13:10 schrieb Mike Frysinger: even then, deleting an ebuild purely due to different copyright is complete bs. The requirement for Gentoo copyright in the main tree is not optional, but has been policy for a very long time. Just because you've been around forever doesnt mean you can break the rules that everyone else is supposed to follow. ++ I'm all for working things out, but this is really non-negotiable at the moment since copyright is legally messy. Patrick couldn't just change the copyright line, and since this is a new package the impact of removing it is least felt if it is done right away. It can certainly be re-introduced with the correct copyright line, assuming it can be legally contributed in this manner (the responsibility of the committer to verify, DCO or not). I think there are benefits if we loosen the policy, but the best I could come up with for making that possible was quite messy with the need to keep track of who contributed what and who assigned copyright on what and all that stuff. One dev contributes an ebuild which is copyright Microsoft GPL-2. I modify 10 lines in it and copyright those Richard Freeman and copyright it GPL-2+. What goes on the copyright line now, and at what point have enough contributions accumulated to allow it to move to GPL-3 if we decide to do that with the whole tree, and remove the MS name since they haven't done anything with it in eons? The draft policy addressed this, but feedback was that it was going to be painful to keep track of who did what, and I can't argue with that. Git blame combined with a tool and database of who has signed an FLA would help a great deal here. The policy itself didn't actually get much argument beyond that, so maybe creating such a tool might be all that is needed to make the switch. For those who haven't read it, my latest drafts: http://dev.gentoo.org/~rich0/copyrightpolicy.xml But, until this becomes actual policy, the current policy stands, whether repoman flags it or not. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Monday 16 February 2015 06:13:10 Mike Frysinger wrote: On Mon, Feb 16, 2015 at 1:16 AM, Alec Warner anta...@gentoo.org wrote: On Sun, Feb 15, 2015 at 8:05 PM, Mike Frysinger vap...@gentoo.org wrote: On Wed, Dec 31, 2014 at 12:21 AM, Patrick Lauer (patrick) patr...@gentoo.org wrote: patrick 14/12/31 05:21:11 Removed: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml Log: QA: Remove package with invalid copyright you do not go reverting code without actually talking to people. if you feel like a revert is necessary, then file a bug. putting a QA tag at the start of the commit message doesn't give you a pass. Normally I'd side with you on this...but I'm fairly sure repoman doesn't let you commit packages to the tree missing these headers. This leads me to believe you didn't use repoman, or ignored it? feel free to grab the code i originally committed and run `repoman full` yourself. no fatal errors. in fact you can see the generated tags in my commit message. Well, AutoRepoman triggered on it. Testing for fun on a random ebuild: RepoMan scours the neighborhood... ebuild.badheader 1 dev-db/hyperdex/hyperdex-1.6.0-r1.ebuild: Invalid Gentoo Copyright on line: 1 Which again leads me to the question: Why are these checks not properly fatal? (And I really do not like having to repeat myself ...) even then, deleting an ebuild purely due to different copyright is complete bs. anyone who understands copyright knows the situation in Gentoo is completely unenforceable. we have no CLA. this was patrick/QA wasting people's time to check a meaningless box. -mike As others have pointed out, policy is policy. Don't shoot the massager. Since I can't just fix the copyright (that would be more wrong) I opted for the easy way out - remove offending bits. Have fun, Patrick
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/16/15 13:31, Andreas K. Huettel wrote: Am Montag 16 Februar 2015, 06:13:10 schrieb Mike Frysinger: even then, deleting an ebuild purely due to different copyright is complete bs. The requirement for Gentoo copyright in the main tree is not optional, but has been policy for a very long time. Just because you've been around forever doesnt mean you can break the rules that everyone else is supposed to follow. I too believe that if you are reverting someone's commit you should at least drop him an email to let him know. How else do you expect him to know he did something wrong? I am a bit worried QA is taking such actions without communicating that with the developer. If you don't let people know they do mistakes, it's likely they will do them again. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJU4dgfAAoJEPqDWhW0r/LCos4P/0PSu6PhS/jJ7md8BN9rcUVZ PUEidEq3RsIBLyN1aaA+Hdexc9D5W8X5qmDqyOvg5L0rY2cT3Xrb+dMOucFQg0SU ODsq3AhIsnkEbZbH+WM89ri8sCCY8xWzhL5dTXlkCb3Hi9VGeC7YTvW8xHyC6xiC Suj33zqM13c2vuYiXDon6MSuMMa7u03AV4ZQSDtU+13cn2jpSR8l9b09phFjyDIZ 2fxPdaWcVW0iNOe94Vf3uavp4LxagMi4/9svxgayjfkqWwDh9uX9ibYNTQUnFsLV FE2xnJki17NhY2+s1A3CPqztuDFtfAinX6JJrNB8AT4VtDM4JvaixVSZ82u00/h3 QP2XvARmriyXUYMSbDrsnHxF0tf21fXOIEXXBFwsLRPRg43MAL1T3A2XtmiUK2sZ R7lA6uq+yPzs16OzAPiEC4PUSY/qXRGu9cUj+z41J49GtckkoL2GlFc3sjo5MhmV C8la6Q0JUKNm6r8joO5IUO0z6HsKjfsWNYDo8pOAZDlFa2Ca+1cox4IxDfTrDEJP B1xs3g9uHPft5Nb4inY3iGsIX/rqKgsR0zIPi475NBOvb/yFFMwpIwp220OwRjLh bfLg0psEYg2guSFYzDTZ5Ocd8p0kSjpuRbSLWozunWilKxR8/3H4CQUHnuInMs/s Mm8xc2USeMGAXktIgsPa =YU+G -END PGP SIGNATURE-
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
El lun, 16-02-2015 a las 06:39 -0500, Mike Frysinger escribió: [...] Anyway, wouldn't have been much more useful for all to spend the effort used in remove the package on simply fixing the header? :/
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
El lun, 16-02-2015 a las 12:46 +0100, Pacho Ramos escribió: El lun, 16-02-2015 a las 06:39 -0500, Mike Frysinger escribió: [...] Anyway, wouldn't have been much more useful for all to spend the effort used in remove the package on simply fixing the header? :/ Ah, ok, I guess it's because of the All rights reserved http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libusbhp/libusbhp-1.0.2.ebuild?revision=1.1 In that case I agree removing the ebuild was the safest approach (even if a mail or a bug would have being nice to notify the committed about that error)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/16/2015 12:44 PM, Markos Chandras wrote: I too believe that if you are reverting someone's commit you should at least drop him an email to let him know. How else do you expect him to know he did something wrong? I am a bit worried QA is taking such actions without communicating that with the developer. If you don't let people know they do mistakes, it's likely they will do them again. I very much agree with this statement - -- Kristian Fiskerstrand Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJU4douAAoJEP7VAChXwav6zwYIAMQfuYsqT+bZNXkW0ngqIniA 0qi68xlzkmOj+ZKucMkAq71ISOFS/cd+5lfJJYfpfdaCQifIcWF2unUKsrG/mBS6 WUhR00rYA8LbIyfBqEkXo0PgiGjAF04lqp3EZwCn9nEQgNNSUb213r/Wyh/pQ7e6 ohvcRKH+zAiHUPdJ+bo5rRIPDO5m+Y2HY/7XouTLkvru0c7KHupQ8BBVG+1uYTqe A72rEEyPJJXKSwj1w5zPwgLLOFkugWyo6YUZdEoJ/+n39VFdLRVdaIkK+VgeMzBV QG2qnGSGKRHX8SDXWI+5k3NMCtSCrIJLlhzmH9QkPI+NY319AbDFHJzYglhZTHk= =WHOc -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On 16 Feb 2015 19:43, Patrick Lauer wrote: On Monday 16 February 2015 06:13:10 Mike Frysinger wrote: even then, deleting an ebuild purely due to different copyright is complete bs. anyone who understands copyright knows the situation in Gentoo is completely unenforceable. we have no CLA. this was patrick/QA wasting people's time to check a meaningless box. As others have pointed out, policy is policy. Don't shoot the massager. again, that's bs. nowhere does the policy state silently delete things without talking to anyone, nor does it state ignore common sense, blindly follow the rules, and act how your think the policy states. nothing here was cause for alarm that could possibly have warranted straight up deletion. Since I can't just fix the copyright (that would be more wrong) considering how copyright *actually* works for us, this statement is fairly ludicrous. I opted for the easy way out - remove offending bits. sorry, but you did it wrong. please don't do it again. -mike signature.asc Description: Digital signature
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On 16 Feb 2015 12:53, Pacho Ramos wrote: El lun, 16-02-2015 a las 12:46 +0100, Pacho Ramos escribió: El lun, 16-02-2015 a las 06:39 -0500, Mike Frysinger escribió: [...] Anyway, wouldn't have been much more useful for all to spend the effort used in remove the package on simply fixing the header? :/ Ah, ok, I guess it's because of the All rights reserved http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libusbhp/libusbhp-1.0.2.ebuild?revision=1.1 In that case I agree removing the ebuild was the safest approach (even if a mail or a bug would have being nice to notify the committed about that error) except for two things: * that phrase is meaningless (legally speaking) and has been for a century [1] * the header explicitly stated GPL-2 license -mike [1] https://en.wikipedia.org/wiki/All_rights_reserved signature.asc Description: Digital signature
Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Mon, Feb 16, 2015 at 6:46 AM, Pacho Ramos pa...@gentoo.org wrote: El lun, 16-02-2015 a las 06:39 -0500, Mike Frysinger escribió: [...] Anyway, wouldn't have been much more useful for all to spend the effort used in remove the package on simply fixing the header? :/ Yeah, let's not bring up the last time somebody tried to do that without any intention of malice that I could detect. The complaints were fairly euthusiastic. For other kinds of issues I agree that being less invasive is better. I do agree that providing notice to the dev when making QA actions of any kind should be standard practice, as brought up by Markos. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/16/15 13:53, Kristian Fiskerstrand wrote: On 02/16/2015 12:44 PM, Markos Chandras wrote: I too believe that if you are reverting someone's commit you should at least drop him an email to let him know. How else do you expect him to know he did something wrong? I am a bit worried QA is taking such actions without communicating that with the developer. If you don't let people know they do mistakes, it's likely they will do them again. I very much agree with this statement https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Communication_When_Making_Fixes So QA has a policy for that and it was not followed... I am sorry but I think Mike is right complaining about the lack of communication. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJU4d6NAAoJEPqDWhW0r/LCMg8QAK+sWgGECTBxI9zLL5xOGtJ7 frGCP9dFQWWdSwuK7sc8JE47zMayCdrHVegRehwsZtrfuho/nufH2Rmp0PCbHAoe Mx8VknGIEKXAiG/udmxFoH8WnLij1MCB+CJhr+R0qtjeyiZb68U051e7eE2NWOt9 KfFcywvhHM4k7ue/2BO4CX+EZIfi29L3lQGp9VjqTHuc4sY670MB2yS0k6P08UOA Lhf9xm1cf/oI6dZWW8FuIfnDDuVp+kssZlYonfLbQrC9nc1yPpsdkvvV9OIj85sJ IiML/xETB4L+AJqaVPrjdGaynza2UsnOtbfsE3P9AvR/Eq/tlb6MDo5hmxCVkuaM 97p/puCMu+NkwpFjkHI6ayX69DIs6N9+LLthTYHg3V2qOvlPXmXQOJbnV+QlWVjr dlzt6Q2sgHoPjeaL5EfZ3q1d6b2VeegWggZLG8dKtSmNsRQwziRyFoND0JgHX1zY dS26MKEbO67kQFdWWV7oNZINNlY0zWYettBk24gmnqUzdPA6kFrnBZ9CaxEPkeYP 3LJZl+QFc23pm6XfoEYuZ1zTmVh1yZICc8hiBLz70fOegodblG+TCUjZ+BfR72bP fkvlBKfEmrrnpFu3wSsUleZm1VbWa1gIa7cQHY0BbK/W7eMI1ZgvJ1M5k1CaSTrM gBFRI9+w3nMl4WN/ADfv =C9Tp -END PGP SIGNATURE-
Re: Re: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
Am Montag 16 Februar 2015, 07:03:18 schrieb Mike Frysinger: except for two things: * that phrase is meaningless (legally speaking) and has been for a century [1] * the header explicitly stated GPL-2 license So you want to change a longstanding policy rule. Right. How about doing this like everyone else and starting a discussion about it? You know, like, talking to people? Just silently committing stuff that goes against standing rules because you disagree with the rules is not the way to go. It's childish and immature. (Remember the ChangeLogs?) -- Andreas K. Huettel Gentoo Linux developer perl, office, comrel, council
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Sun, Feb 15, 2015 at 8:05 PM, Mike Frysinger vap...@gentoo.org wrote: On Wed, Dec 31, 2014 at 12:21 AM, Patrick Lauer (patrick) patr...@gentoo.org wrote: patrick 14/12/31 05:21:11 Removed: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml Log: QA: Remove package with invalid copyright you do not go reverting code without actually talking to people. if you feel like a revert is necessary, then file a bug. putting a QA tag at the start of the commit message doesn't give you a pass. Normally I'd side with you on this...but I'm fairly sure repoman doesn't let you commit packages to the tree missing these headers. This leads me to believe you didn't use repoman, or ignored it? -A -mike
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
On Wed, Dec 31, 2014 at 12:21 AM, Patrick Lauer (patrick) patr...@gentoo.org wrote: patrick 14/12/31 05:21:11 Removed: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml Log: QA: Remove package with invalid copyright you do not go reverting code without actually talking to people. if you feel like a revert is necessary, then file a bug. putting a QA tag at the start of the commit message doesn't give you a pass. -mike
