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 wrote: > On Sun, Feb 15, 2015 at 8:05 PM, Mike Frysinger wrote: >> On Wed, Dec 31, 2014 at 12: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 >> >> 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 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: [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 wrote: > > On Sun, Feb 15, 2015 at 8:05 PM, Mike Frysinger wrote: > >> On Wed, Dec 31, 2014 at 12: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 > >> > >> 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: 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 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
-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 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: 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 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
[gentoo-dev] Making more repoman checks fatal
Right now repoman is relatively permissive - it whines about many things, but treats many issues as warning. The result is that many ebuilds get committed with 'minor' cosmetic issues which then someone more OCD than the original committer cleans up, making pretty much everyone involved more unhappy. There's no reason to not error out on, for example, an invalid RESTRICT. Just printing a message is relatively useless. Thus I suggest making the following warnings proper errors: (Taken from current repoman 'qawarnings' set) "changelog.missing", "changelog.notadded", "digest.assumed", "digest.unused", "ebuild.notadded", "ebuild.nesteddie", "DESCRIPTION.toolong", "RESTRICT.invalid", "ebuild.minorsyn", "ebuild.badheader", "metadata.warning", "LIVEVCS.stable", "LIVEVCS.unmasked", Most of these have few or no occurrences in the current tree, so changing the default from warn to error won't get in the way of the normal workflow. (A few of them, like DESCRIPTION.toolong, still have about a dozen leftovers, but that should be easy to fix) Have fun, Patrick
Re: [gentoo-dev] Making more repoman checks fatal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 FWIW: I'm in the "warnings are pointless, either we care about something (so make it an error), or we don't (so get rid of it)". - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlTh6lUACgkQRtClrXBQc7UXHgD9EG6jZBwJ/wvBY0E+XJvuCB8Q D4Al3H2n2XyYXllCmYUA/1UHAmxBpb/rbNGPE3w/I3JmxE/yNoa57bxEIxDwAREB =DD9H -END PGP SIGNATURE-
Re: [gentoo-dev] Making more repoman checks fatal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/02/15 14:02, Alexander Berntsen wrote: > FWIW: I'm in the "warnings are pointless, either we care about > something (so make it an error), or we don't (so get rid of it)". s/\./ camp./ (I accidentally a word...) - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlTh6uIACgkQRtClrXBQc7WOPQEAs4AmG2HHxbjWe54j8zHfN9S8 0IpQPJ68mYli2adDNH4BAIox20ink9c2Ntd/Nsk80jyqWpKsNFd0UcJzLALnDu/I =ldpG -END PGP SIGNATURE-
Re: [gentoo-dev] Making more repoman checks fatal
On Feb 16, 2015 8:01 AM, "Patrick Lauer" wrote: > > Right now repoman is relatively permissive - it whines about many things, but > treats many issues as warning. > The result is that many ebuilds get committed with 'minor' cosmetic issues > which then someone more OCD than the original committer cleans up, making > pretty much everyone involved more unhappy. > > There's no reason to not error out on, for example, an invalid RESTRICT. Just > printing a message is relatively useless. > > > Thus I suggest making the following warnings proper errors: > > (Taken from current repoman 'qawarnings' set) > > "changelog.missing", > "changelog.notadded", > "digest.assumed", > "digest.unused", > "ebuild.notadded", > "ebuild.nesteddie", > "DESCRIPTION.toolong", > "RESTRICT.invalid", > "ebuild.minorsyn", > "ebuild.badheader", > "metadata.warning", > "LIVEVCS.stable", > "LIVEVCS.unmasked", > > Most of these have few or no occurrences in the current tree, so changing the > default from warn to error won't get in the way of the normal workflow. > > (A few of them, like DESCRIPTION.toolong, still have about a dozen leftovers, > but that should be easy to fix) > > Have fun, > > Patrick > I would also like to put forward the idea of a pedantic flag, like with GCC, To make all warnings fatal. Or at minimum, make a lesser flag where certain flags that are not normally fatal, would become fatal.
Re: [gentoo-dev] Making more repoman checks fatal
> Thus I suggest making the following warnings proper errors: > > (Taken from current repoman 'qawarnings' set) > > "changelog.missing", > "changelog.notadded", > "digest.assumed", > "digest.unused", > "ebuild.notadded", > "ebuild.nesteddie", > "DESCRIPTION.toolong", > "RESTRICT.invalid", > "ebuild.minorsyn", > "ebuild.badheader", > "metadata.warning", > "LIVEVCS.stable", > "LIVEVCS.unmasked", > Yes please. And in addition "dependency.perlcore" -- Andreas K. Huettel Gentoo Linux developer perl, office, comrel, council
Re: [gentoo-dev] Making more repoman checks fatal
El lun, 16-02-2015 a las 21:00 +0800, Patrick Lauer escribió: [...] > I agree
Re: [gentoo-dev] Making more repoman checks fatal
On 16 Feb 2015 21:00, Patrick Lauer wrote: > Thus I suggest making the following warnings proper errors: some of these are because they produce false positives. at least these bugs probably need to be fixed first: https://bugs.gentoo.org/405017 https://bugs.gentoo.org/488836 https://bugs.gentoo.org/533460 -mike signature.asc Description: Digital signature
[gentoo-dev] About reducing or even removing stable tree for some arches
Hello Every day I am hitting tons of blockers stabilizations and keywording requests for alpha, sparc, ia64, ppc and ppc64. Again, I would suggest to either decrease radically the amount of stable packages of some of that arches or even make them testing only. For reducing their stable tree, my suggestion would be to either keep their current stage3 packages stable or stage3+some concrete (and public) list of packages. Currently situation is not good at all as we rely on mostly one member needing to handle most stable work and, if any stablereq has any issue leading to it not being able to be handled in an "automated" way, the bug gets blocked for months. Also, keywording work is mostly stalled on this arches as it's done by even less people. The current policy of maintainers dropping keywords after 90 days is simply not applied because it leads up to that maintainer needing to kill himself that keyword and ALL the reverse deps keywords and, then, all that effort should probably be replaced by making the opposite, I mean, reducing the stable tree of that arches to a minimum and moving all the other packages to testing. The main advantage of this is that it needs maybe more effort in one round but it solves the problem for the future. On the other hand trying to kill keywords of a package *and all its reverse deps* requires a lot of work every time the problem appears. Of course I volunteer for doing the work of reducing that stable trees if relevant arch teams agree. Thanks a lot for your help
Re: [gentoo-dev] Making more repoman checks fatal
On Mon, Feb 16, 2015 at 11:19 AM, Mike Frysinger wrote: > On 16 Feb 2015 21:00, Patrick Lauer wrote: >> Thus I suggest making the following warnings proper errors: > > some of these are because they produce false positives. at least these bugs > probably need to be fixed first: > https://bugs.gentoo.org/405017 > https://bugs.gentoo.org/488836 > https://bugs.gentoo.org/533460 > -mike I think that just the last bug is still valid. []s -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] Making more repoman checks fatal
On Mon, 16 Feb 2015 21:00:16 +0800 Patrick Lauer wrote: > Right now repoman is relatively permissive - it whines about many things, but > treats many issues as warning. > The result is that many ebuilds get committed with 'minor' cosmetic issues > which then someone more OCD than the original committer cleans up, making > pretty much everyone involved more unhappy. > > There's no reason to not error out on, for example, an invalid RESTRICT. Just > printing a message is relatively useless. > > > Thus I suggest making the following warnings proper errors: > > (Taken from current repoman 'qawarnings' set) [...] > "ebuild.minorsyn", Not this one, please. It gives tons of false warnings, e.g.: ebuild.minorsyn 1 media-video/kino/kino-1.3.4.ebuild: Unquoted Variable on line: 95 It also have problems with nested "\"\"" constructs. I can't remember example right now. > "ebuild.badheader", > "metadata.warning", > "LIVEVCS.stable", > "LIVEVCS.unmasked", > > Most of these have few or no occurrences in the current tree, so changing the > default from warn to error won't get in the way of the normal workflow. > > (A few of them, like DESCRIPTION.toolong, still have about a dozen leftovers, > but that should be easy to fix) I don't see any reasons to make this one fatal. Best regards, Andrew Savchenko pgpUp8BCODEiO.pgp Description: 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 Mon, Feb 16, 2015 at 7:44 AM, Joshua Kinard 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
Re: [gentoo-dev] About reducing or even removing stable tree for some arches
On Mon, Feb 16, 2015 at 8:34 AM, Pacho Ramos wrote: > > The current policy of maintainers dropping keywords after 90 days is > simply not applied because it leads up to that maintainer needing to > kill himself that keyword and ALL the reverse deps keywords A published script might ease that, especially with the move to git (where that could be done in a single commit). Another option is to just allow the keywords to be dropped without fixing the reverse deps on those archs in these circumstances, though that can be messier for users. -- Rich
Re: [gentoo-dev] About reducing or even removing stable tree for some arches
El lun, 16-02-2015 a las 10:09 -0500, Rich Freeman escribió: > On Mon, Feb 16, 2015 at 8:34 AM, Pacho Ramos wrote: > > > > The current policy of maintainers dropping keywords after 90 days is > > simply not applied because it leads up to that maintainer needing to > > kill himself that keyword and ALL the reverse deps keywords > > A published script might ease that, especially with the move to git > (where that could be done in a single commit). That looks interesting... but I don't think we should wait until git migration is done. Well, since I joined at 2009 I am earing about git migration and it's never done, then, I would do that job (even manually with CVS and tons of commits) without waiting for git. > > Another option is to just allow the keywords to be dropped without > fixing the reverse deps on those archs in these circumstances, though > that can be messier for users. > Yeah, that is another option... but I think that it can be worse for the users as, instead of they reading a news item informing about tons of packages being now moved to testing (or all their tree) and they preparing to that, they will start to get portage errors from time to time depending on their installed packages :/
Re: [gentoo-dev] About reducing or even removing stable tree for some arches
On 02/16/15 08:34, Pacho Ramos wrote: Hello Every day I am hitting tons of blockers stabilizations and keywording requests for alpha, sparc, ia64, ppc and ppc64. The powerpc team figured we'd deal with this by being "lax" about keywording/stabilization and catch problems in subsequent bug reports to increase our throughput. We didn't want to drop the entire arch to ~. The team hasn't met since last august, and we should discuss this again. But we decided then that ago would do stabilization and the rest of us would do keywording. As far as I'm concerned, I'm happy to drop all desktop-ish packages to ~arch, but keep the more server-ish, system-ish packages as stable. Controlling @system with stable keywords is very useful for building stages so I'm reluctant to give that up. So maybe we can just adopt the policy that any ppc/ppc64 package which depends on X can be dropped to ~. Thanks a lot for your help No problem. Can you categorize where most of the blockers are coming from? Are they mostly desktop? Comments from other ppc people? -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] About reducing or even removing stable tree for some arches
On 02/16/2015 10:36, Anthony G. Basile wrote: > On 02/16/15 08:34, Pacho Ramos wrote: >> Hello >> >> Every day I am hitting tons of blockers stabilizations and keywording >> requests for alpha, sparc, ia64, ppc and ppc64. > > The powerpc team figured we'd deal with this by being "lax" about > keywording/stabilization and catch problems in subsequent bug reports to > increase our throughput. We didn't want to drop the entire arch to ~. The > team hasn't met since last august, and we should discuss this again. But we > decided then that ago would do stabilization and the rest of us would do > keywording. > > As far as I'm concerned, I'm happy to drop all desktop-ish packages to ~arch, > but keep the more server-ish, system-ish packages as stable. Controlling > @system with stable keywords is very useful for building stages so I'm > reluctant to give that up. So maybe we can just adopt the policy that any > ppc/ppc64 package which depends on X can be dropped to ~. :: puts on a flame-retardant suit :: Once we complete the git migration, why not take a second look on using a stable/testing/unstable (or -RELEASE/-STABLE/-CURRENT) system used by Debian and FreeBSD? That should be entirely doable under a git tree versus CVS. It would require beefing releng up again and a whole host of other issues. Keep the core git tree constantly rolling forward, have a dedicated branch get cut say, once a year (or less -- Debian is ~18mo?), another group of devs works on stabilizing that (and periodically cherrypicking from the master branch), and when the time comes, totally freeze that for security revs only by a smaller group of devs? -- 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 02/16/2015 09:04, Rich Freeman wrote: > On Mon, Feb 16, 2015 at 7:44 AM, Joshua Kinard 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] About reducing or even removing stable tree for some arches
El lun, 16-02-2015 a las 10:36 -0500, Anthony G. Basile escribió: > On 02/16/15 08:34, Pacho Ramos wrote: > > Hello > > > > Every day I am hitting tons of blockers stabilizations and keywording > > requests for alpha, sparc, ia64, ppc and ppc64. > > The powerpc team figured we'd deal with this by being "lax" about > keywording/stabilization and catch problems in subsequent bug reports to > increase our throughput. We didn't want to drop the entire arch to ~. > The team hasn't met since last august, and we should discuss this > again. But we decided then that ago would do stabilization and the rest > of us would do keywording. > > As far as I'm concerned, I'm happy to drop all desktop-ish packages to > ~arch, but keep the more server-ish, system-ish packages as stable. > Controlling @system with stable keywords is very useful for building > stages so I'm reluctant to give that up. So maybe we can just adopt the > policy that any ppc/ppc64 package which depends on X can be dropped to ~. > Would you mind generating a list of installed packages do you have now currently on your ppc* boxes? That would be a good start point to know what to preserve :) (I remember I was able to found the list of packages in stage3 some months ago but I am now unable to :S) > > Thanks a lot for your help > > > > No problem. Can you categorize where most of the blockers are coming > from? Are they mostly desktop? > They come from multiple places, for example I am now fighting with getting ipython finally stabilized after months of waiting because the deps hell in python packages (as package A needs package B, B needs C and D maintained by others... and the chain keeps growing and growing). With the current way of passing the stabilization responsibility to mostly Ago the problem is that he needs to do stabilization in a more "automatized" way as he needs to take care of a lot of arches (all but hppa). Then, most of this bugs get stalled forever as we cannot rely on any arch team member apart of him to take care of trying to do that job. And because of this not only minor arches, even amd64 is blocked by this. On the other hand, arm team has already being able to do that one as his arch team members have found all the needed packages to stabilize by themselves for ARM :| > Comments from other ppc people? >
Re: [gentoo-dev] Making more repoman checks fatal
On Mon, 16 Feb 2015 21:00:16 +0800 Patrick Lauer wrote: > Right now repoman is relatively permissive - it whines about many > things, but treats many issues as warning. > The result is that many ebuilds get committed with 'minor' cosmetic > issues which then someone more OCD than the original committer cleans > up, making pretty much everyone involved more unhappy. > > There's no reason to not error out on, for example, an invalid > RESTRICT. Just printing a message is relatively useless. > > > Thus I suggest making the following warnings proper errors: > > (Taken from current repoman 'qawarnings' set) > > "changelog.missing", > "changelog.notadded", > "digest.assumed", > "digest.unused", > "ebuild.notadded", > "ebuild.nesteddie", > "DESCRIPTION.toolong", > "RESTRICT.invalid", > "ebuild.minorsyn", > "ebuild.badheader", > "metadata.warning", > "LIVEVCS.stable", > "LIVEVCS.unmasked", > > Most of these have few or no occurrences in the current tree, so > changing the default from warn to error won't get in the way of the > normal workflow. > > (A few of them, like DESCRIPTION.toolong, still have about a dozen > leftovers, but that should be easy to fix) > > Have fun, > > Patrick > While I can agree to the principal of this, Unfortunately I maintain several pkgs that I would love to clean out old versions of that trigger several of these, but can't. (But I am getting closer to being able to clean them) If I recall correctly they are: "ebuild.minorsyn", "ebuild.badheader", plus a couple other odd ones Portage ebuild triggers minorsyn due to a false positive quoting issue. -- Brian Dolbec
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 Mon, Feb 16, 2015 at 11:02 AM, Joshua Kinard 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: [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 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: 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 wrote: > On Mon, Feb 16, 2015 at 1:16 AM, Alec Warner wrote: > > On Sun, Feb 15, 2015 at 8:05 PM, Mike Frysinger > wrote: > >> On Wed, Dec 31, 2014 at 12: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 > >> > >> 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: [gentoo-dev] About reducing or even removing stable tree for some arches
On 02/16/15 11:05, Pacho Ramos wrote: El lun, 16-02-2015 a las 10:36 -0500, Anthony G. Basile escribió: On 02/16/15 08:34, Pacho Ramos wrote: Hello Every day I am hitting tons of blockers stabilizations and keywording requests for alpha, sparc, ia64, ppc and ppc64. The powerpc team figured we'd deal with this by being "lax" about keywording/stabilization and catch problems in subsequent bug reports to increase our throughput. We didn't want to drop the entire arch to ~. The team hasn't met since last august, and we should discuss this again. But we decided then that ago would do stabilization and the rest of us would do keywording. As far as I'm concerned, I'm happy to drop all desktop-ish packages to ~arch, but keep the more server-ish, system-ish packages as stable. Controlling @system with stable keywords is very useful for building stages so I'm reluctant to give that up. So maybe we can just adopt the policy that any ppc/ppc64 package which depends on X can be dropped to ~. Would you mind generating a list of installed packages do you have now currently on your ppc* boxes? That would be a good start point to know what to preserve :) (I remember I was able to found the list of packages in stage3 some months ago but I am now unable to :S) Yes and no. I'd like to hear from the other ppc team members, otherwise you'll just get my wish list. Thanks a lot for your help No problem. Can you categorize where most of the blockers are coming from? Are they mostly desktop? They come from multiple places, for example I am now fighting with getting ipython finally stabilized after months of waiting because the deps hell in python packages (as package A needs package B, B needs C and D maintained by others... and the chain keeps growing and growing). Ah yes. The python and ruby dep hell. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] About reducing or even removing stable tree for some arches
On Mon, Feb 16, 2015 at 4:22 PM, Anthony G. Basile wrote: >> They come from multiple places, for example I am now fighting with >> getting ipython finally stabilized after months of waiting because the >> deps hell in python packages (as package A needs package B, B needs C >> and D maintained by others... and the chain keeps growing and growing). > > > Ah yes. The python and ruby dep hell. I suspect the python depgraph gets a lot bigger when you include testing-related deps. It might be worth use-masking test on some of the smaller archs. If anyone thinks that's a good/bad idea, it would be nice to hear about it.
Re: [gentoo-dev] About reducing or even removing stable tree for some arches
On Mon, Feb 16, 2015 at 02:34:50PM +0100, Pacho Ramos wrote: > Hello > > Every day I am hitting tons of blockers stabilizations and keywording > requests for alpha, sparc, ia64, ppc and ppc64. > > Again, I would suggest to either decrease radically the amount of stable > packages of some of that arches or even make them testing only. > > For reducing their stable tree, my suggestion would be to either keep > their current stage3 packages stable or stage3+some concrete (and > public) list of packages. > > Currently situation is not good at all as we rely on mostly one member > needing to handle most stable work and, if any stablereq has any issue > leading to it not being able to be handled in an "automated" way, the > bug gets blocked for months. Also, keywording work is mostly stalled on > this arches as it's done by even less people. > > The current policy of maintainers dropping keywords after 90 days is > simply not applied because it leads up to that maintainer needing to > kill himself that keyword and ALL the reverse deps keywords and, then, > all that effort should probably be replaced by making the opposite, I > mean, reducing the stable tree of that arches to a minimum and moving > all the other packages to testing. The main advantage of this is that it > needs maybe more effort in one round but it solves the problem for the > future. On the other hand trying to kill keywords of a package *and all > its reverse deps* requires a lot of work every time the problem appears. > > Of course I volunteer for doing the work of reducing that stable trees > if relevant arch teams agree. I responded to this earlier, but I don't know what happened to my message since I didn't see it come back. I propose that we look at switching these arch's to dev or exp in the profiles. That way these arch teams can independently stabilize packages they wish to stabilize without holding up the rest of us. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] About reducing or even removing stable tree for some arches
On Mon, Feb 16, 2015 at 02:34:50PM +0100, Pacho Ramos wrote: > Hello > > Every day I am hitting tons of blockers stabilizations and keywording > requests for alpha, sparc, ia64, ppc and ppc64. > > Again, I would suggest to either decrease radically the amount of stable > packages of some of that arches or even make them testing only. > > For reducing their stable tree, my suggestion would be to either keep > their current stage3 packages stable or stage3+some concrete (and > public) list of packages. > > Currently situation is not good at all as we rely on mostly one member > needing to handle most stable work and, if any stablereq has any issue > leading to it not being able to be handled in an "automated" way, the > bug gets blocked for months. Also, keywording work is mostly stalled on > this arches as it's done by even less people. > > The current policy of maintainers dropping keywords after 90 days is > simply not applied because it leads up to that maintainer needing to > kill himself that keyword and ALL the reverse deps keywords and, then, > all that effort should probably be replaced by making the opposite, I > mean, reducing the stable tree of that arches to a minimum and moving > all the other packages to testing. The main advantage of this is that it > needs maybe more effort in one round but it solves the problem for the > future. On the other hand trying to kill keywords of a package *and all > its reverse deps* requires a lot of work every time the problem appears. I think the cleanest way forward would be to mark these arch's dev or exp in the profiles. That way, maintainers don't have to worry about them and the people maintaining the arch's can determine what needs to be stabilized at their own paces. William signature.asc Description: Digital signature
Re: [gentoo-dev] About reducing or even removing stable tree for some arches
On Mon, Feb 16, 2015 at 10:59 AM, Joshua Kinard wrote: > > Keep the core git tree constantly rolling forward, have a dedicated branch get > cut say, once a year (or less -- Debian is ~18mo?), another group of devs > works > on stabilizing that (and periodically cherrypicking from the master branch), > and when the time comes, totally freeze that for security revs only by a > smaller group of devs? That might actually make sense for the minor archs. I'm not sure how popular it would be though for amd64. I doubt I'd use it. I think one of the big benefits of Gentoo stable is that you can have a fairly mature core system, but still track bleeding-edge for specific packages you're interested in. You can't really do that with almost any other distro. I might want to use a live version of chromium if I contribute to it, but I don't want that new release of KDE that everybody says is buggy, etc (contrived example - I've almost forgotten about 4.0 now). If we were going to be more release-based it might make more sense to do it in the sense of CI. Maybe have a daily release and a live branch, with the former being the intended target for a typical user. The daily release would be tested automatically before it was actually released (obviously this can only be done to a limited extent). The overall experience wouldn't change much, but at least the daily emerge-webrsync user would be assured to not have glaring keyword errors and such in their tree that repoman would catch. -- Rich
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 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
[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] About reducing or even removing stable tree for some arches
Dnia 2015-02-16, o godz. 10:37:12 William Hubbs napisał(a): > On Mon, Feb 16, 2015 at 02:34:50PM +0100, Pacho Ramos wrote: > > Hello > > > > Every day I am hitting tons of blockers stabilizations and keywording > > requests for alpha, sparc, ia64, ppc and ppc64. > > > > Again, I would suggest to either decrease radically the amount of stable > > packages of some of that arches or even make them testing only. > > > > For reducing their stable tree, my suggestion would be to either keep > > their current stage3 packages stable or stage3+some concrete (and > > public) list of packages. > > > > Currently situation is not good at all as we rely on mostly one member > > needing to handle most stable work and, if any stablereq has any issue > > leading to it not being able to be handled in an "automated" way, the > > bug gets blocked for months. Also, keywording work is mostly stalled on > > this arches as it's done by even less people. > > > > The current policy of maintainers dropping keywords after 90 days is > > simply not applied because it leads up to that maintainer needing to > > kill himself that keyword and ALL the reverse deps keywords and, then, > > all that effort should probably be replaced by making the opposite, I > > mean, reducing the stable tree of that arches to a minimum and moving > > all the other packages to testing. The main advantage of this is that it > > needs maybe more effort in one round but it solves the problem for the > > future. On the other hand trying to kill keywords of a package *and all > > its reverse deps* requires a lot of work every time the problem appears. > > I think the cleanest way forward would be to mark these arch's dev or > exp in the profiles. That way, maintainers don't have to worry about > them and the people maintaining the arch's can determine what needs to > be stabilized at their own paces. Sounds like a very bad idea. This will only cause developers to frequently break the tree accidentally because of no repoman checks by default. -- Best regards, Michał Górny pgpRPvylF7kHi.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Making more repoman checks fatal
On Mon, Feb 16, 2015 at 8:00 AM, Patrick Lauer wrote: > Thus I suggest making the following warnings proper errors: > > (Taken from current repoman 'qawarnings' set) > > "changelog.missing", > "changelog.notadded", These two are pretty much irrelevant now that repoman auto-generates ChangeLog, so making them fatal doesn't really matter. > "digest.unused", This pretty much never pops up since repoman regens the Manifest before committing anyway. > "ebuild.notadded", This automatically becomes fatal when you run repoman in commit mode. It is a bit pointless to even run this check before that point. > "DESCRIPTION.toolong", I am of the opinion that strictly enforcing a length on DESCRIPTION is stupid. Keep this as a warning please. > "ebuild.minorsyn", That should not be fatal. There is little value, and there are false positives in any case.
