* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1447458773.ad4c142684afb096e8fff2937ae5c5c3385dd22e.mgorny@gentoo> @ 2015-11-16 9:01 ` Alexis Ballier 2015-11-16 9:06 ` Justin Lecher (jlec) 0 siblings, 1 reply; 119+ messages in thread From: Alexis Ballier @ 2015-11-16 9:01 UTC (permalink / raw To: Michał Górny; +Cc: gentoo-dev On Fri, 13 Nov 2015 23:53:05 +0000 (UTC) "Michał Górny" <mgorny@gentoo.org> wrote: > commit: ad4c142684afb096e8fff2937ae5c5c3385dd22e > Author: Michał Górny <mgorny <AT> gentoo <DOT> org> > AuthorDate: Fri Nov 13 18:46:33 2015 +0000 > Commit: Michał Górny <mgorny <AT> gentoo <DOT> org> > CommitDate: Fri Nov 13 23:52:53 2015 +0000 > URL: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad4c1426 > > autotools-{utils,multilib}.eclass: Ban for EAPI=6 > > Ban autotools-utils.eclass and dependant autotools-multilib.eclass for > EAPI=6 to avoid them being accidentally enabled. The former eclass > should be replaced with inline code, the latter with > multilib-minimal.eclass. Not that I particularly like those eclasses, but I seem to have missed the deprecation warnings for these. I hope you're planning in submitting patches "fixing" consumers... Alexis. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-11-16 9:01 ` [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ Alexis Ballier @ 2015-11-16 9:06 ` Justin Lecher (jlec) 2015-11-16 9:14 ` Alexis Ballier 0 siblings, 1 reply; 119+ messages in thread From: Justin Lecher (jlec) @ 2015-11-16 9:06 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16/11/15 10:01, Alexis Ballier wrote: > On Fri, 13 Nov 2015 23:53:05 +0000 (UTC) "Michał Górny" > <mgorny@gentoo.org> wrote: > >> commit: ad4c142684afb096e8fff2937ae5c5c3385dd22e Author: >> Michał Górny <mgorny <AT> gentoo <DOT> org> AuthorDate: Fri Nov >> 13 18:46:33 2015 +0000 Commit: Michał Górny <mgorny <AT> >> gentoo <DOT> org> CommitDate: Fri Nov 13 23:52:53 2015 +0000 >> URL: >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad4c1426 >> >> autotools-{utils,multilib}.eclass: Ban for EAPI=6 >> >> Ban autotools-utils.eclass and dependant >> autotools-multilib.eclass for EAPI=6 to avoid them being >> accidentally enabled. The former eclass should be replaced with >> inline code, the latter with multilib-minimal.eclass. > > > Not that I particularly like those eclasses, but I seem to have > missed the deprecation warnings for these. I hope you're planning > in submitting patches "fixing" consumers... Probably the developers should fix their ebuilds when they bump to EAPI=6. While I haven't looked at the change exactly, Michał announced it as a EAPI >= 6 Ban. So no backwards breakages expected. Justin -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWSZyJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiHY4P/0TjhS4isDESbDHkSgcWhdgs aSexsiCJs1bCaTjGAH2Hn8cPaesV0CO96BMFWgjq/io/B+N1x+h5RbhbI/zXHXpK I9sziWWI68J7SvumVEtkoccM4bdWDKj+pdsqCnyJYp0qkTVZbUBNK0vpUYBhIQRt 4LMCEZvo9me1FmBtdv5RssqkLw2nqcb3sfsQ5uQ7icdIR1rRp9OTNdT3/LQAOQ3l nGDz/fZpHOlUhyMdCEtSzv51ZBvejFcuRrSea2jnqOdkcnDwOY8Fo9HH0iv1rVmd SZkAV4yZSz+0OveisjPhQSa1h/uquv49KLcLp6CfPA5228POy/RhFwGx4ZLRhbe3 tlFUApr4ozI4Danry5SlMu2YadJdf+zPu7e/FLwdIVzv7eqZa8ov8cOHyNICVKpr JZsFvk/7pyL0TB+zfo/MZCU5KY72HOcmi5yL7FpDyYg0m/0cn6bH+FHN/rUxpuLT inztt4MThZUb+Oubd40GRpD8xSmhgQYo90Us10tb/6xU5tGD7+ZtvENKvPQsMQgp Zh0tkzpp+jJpqlJ7lupa/f5EjWxhXefD5fkrtxjTAO9aIU6JoY6MWd3uqKndSwjA WrdxnX/lPkDSTqLqPYvPxLYebBuAyKojeIEGaF558ELcwUxNRJdK84CqRsNsLwHe vtEeQFPh0f3cl/+9EZju =TvwF -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-11-16 9:06 ` Justin Lecher (jlec) @ 2015-11-16 9:14 ` Alexis Ballier 2015-11-16 9:29 ` Justin Lecher (jlec) 0 siblings, 1 reply; 119+ messages in thread From: Alexis Ballier @ 2015-11-16 9:14 UTC (permalink / raw To: gentoo-dev On Mon, 16 Nov 2015 10:06:17 +0100 "Justin Lecher (jlec)" <jlec@gentoo.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 16/11/15 10:01, Alexis Ballier wrote: > > On Fri, 13 Nov 2015 23:53:05 +0000 (UTC) "Michał Górny" > > <mgorny@gentoo.org> wrote: > > > >> commit: ad4c142684afb096e8fff2937ae5c5c3385dd22e Author: > >> Michał Górny <mgorny <AT> gentoo <DOT> org> AuthorDate: Fri Nov > >> 13 18:46:33 2015 +0000 Commit: Michał Górny <mgorny <AT> > >> gentoo <DOT> org> CommitDate: Fri Nov 13 23:52:53 2015 +0000 > >> URL: > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad4c1426 > >> > >> autotools-{utils,multilib}.eclass: Ban for EAPI=6 > >> > >> Ban autotools-utils.eclass and dependant > >> autotools-multilib.eclass for EAPI=6 to avoid them being > >> accidentally enabled. The former eclass should be replaced with > >> inline code, the latter with multilib-minimal.eclass. > > > > > > Not that I particularly like those eclasses, but I seem to have > > missed the deprecation warnings for these. I hope you're planning > > in submitting patches "fixing" consumers... > > Probably the developers should fix their ebuilds when they bump to > EAPI=6. While I haven't looked at the change exactly, Michał announced > it as a EAPI >= 6 Ban. So no backwards breakages expected. Probably those that want to ban it should fix the(ir) tree so that developers have no pain in bumping to eapi6? While I agree we should move away from those eclasses, the "I decided to throw the crap at other developers with eapi6 without deprecation period" is a bit hard to grasp. Esp. when these eclasses were advertised as the way to go not so long ago... ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-11-16 9:14 ` Alexis Ballier @ 2015-11-16 9:29 ` Justin Lecher (jlec) 2015-11-16 9:52 ` Alexis Ballier 0 siblings, 1 reply; 119+ messages in thread From: Justin Lecher (jlec) @ 2015-11-16 9:29 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16/11/15 10:14, Alexis Ballier wrote: > Probably those that want to ban it should fix the(ir) tree so that > developers have no pain in bumping to eapi6? Versioned APIs are made to have incompatible changes. What do you like to see? Someone dropping all usages of that eclass from all ebuilds which are using it so that the maintainer can bump without thinking? I agree with you later statement that the eclasses have been announced to be a great solution when using autotools based packages, and dropping it now means going back to the old. But the changes needed are just straight forward, drop the eclass and use the default functions of EAPI=6. Plus the autotools.eclass when you need to run autoreconf and friends. > While I agree we should move away from those eclasses, the "I > decided to throw the crap at other developers with eapi6 without > deprecation period" is a bit hard to grasp. Esp. when these > eclasses were advertised as the way to go not so long ago... > I don't really understand what deprecation you like to see? We cannot use EAPI=6 right now and when it starts to exist, nothing will be broken. So you have some to time to adopt your thinking until you write your first ebuild in EAPI=6. At which particular point do you seen problems coming up? What do you think will make maintainers struggle with that change? Justin -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWSaIHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiQqgQAJPqJhNCzec5w/wBNhMAI/AO gu086aIIwHoc1mRCPtkgrfY/UhT6unO3U+V+/MBnyRJB5tJc+6AgM//ovt8ctsyb Aylog8w77mT/v9GULq1PPPRIy0p+Eh3XvhxNWdFZgu4BAVde/4b3rQEklIPiwAiC FQy23LQEZh4wG8CldoR6ULBR0CUO8Ff6xNFVqXvgjhnH+I7BehRP47OE5SiiobCK /4bKb9UjKZqnrttagPlaf6DrzidJd4XgHPrhQSoTA6uLubB0uR7EdrwlgYlR3FES LWbT4kO9RG9GZo1y4mrNxGTugiF3OFwJX5UHJT55lwNPDHcUsNhl3Yyjb9Vc9f9W Ro/6x7gY5dchDARy1LU3419tRzPGvxeyKkc6Z21Ie374LQYuhhKQiPzjW6oSc+j2 MFDzjBphdqXuiSYeC608Q3KGoYruV2fSGhqQDdAsSADkBBXktBApOZpjyrYXv6W1 xwN/FYHE21lZHjCTUJQEz2+5fdZ0VxRtQPQKautkB8+rhfobrexafMVYt8hjB6fG JvCTOb5Yo8VpWs7i/Zls5jB87y6uYrSFGlbbCrMu6vO7m/KrhZZjQ9dpHpeQ78qj grhcoxi2xtvfa72j/eVxgDYHhXjoJLmJ/60dsUt75IwAcVhtwEg6OWVowXxAGmgD DNG/UIoC9yKzVxkAaEm/ =zJp2 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-11-16 9:29 ` Justin Lecher (jlec) @ 2015-11-16 9:52 ` Alexis Ballier 2015-11-16 12:08 ` Rich Freeman 0 siblings, 1 reply; 119+ messages in thread From: Alexis Ballier @ 2015-11-16 9:52 UTC (permalink / raw To: gentoo-dev On Mon, 16 Nov 2015 10:29:43 +0100 "Justin Lecher (jlec)" <jlec@gentoo.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 16/11/15 10:14, Alexis Ballier wrote: > > Probably those that want to ban it should fix the(ir) tree so that > > developers have no pain in bumping to eapi6? > > Versioned APIs are made to have incompatible changes. What do you like > to see? deprecation warnings for some time or.. > Someone dropping all usages of that eclass from all ebuilds > which are using it so that the maintainer can bump without thinking? this would be preferred :) [...] > > While I agree we should move away from those eclasses, the "I > > decided to throw the crap at other developers with eapi6 without > > deprecation period" is a bit hard to grasp. Esp. when these > > eclasses were advertised as the way to go not so long ago... > > > > I don't really understand what deprecation you like to see? RepoMan scours the neighborhood... inherit.deprecated 1 x11-wm/xmonad-contrib/xmonad-contrib-0.11.2.ebuild: please migrate from 'base' (no replacement) on line: 10 these warnings have been there for ages and for several eclasses > We cannot > use EAPI=6 right now and when it starts to exist, nothing will be > broken. So you have some to time to adopt your thinking until you > write your first ebuild in EAPI=6. > > At which particular point do you seen problems coming up? What do you > think will make maintainers struggle with that change? Right. With our always decreasing, soon to be negative, number of open bugs, all those shiny areas where fellow developers spend more time looking for something to do rather than doing it, we should be thankful to have at least some ebuild rewrite to do ! :) More seriously, the problem is not in the technical way it is done (changing eclass API with EAPI is a nice proper way), but in adding useless burden. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-11-16 9:52 ` Alexis Ballier @ 2015-11-16 12:08 ` Rich Freeman 0 siblings, 0 replies; 119+ messages in thread From: Rich Freeman @ 2015-11-16 12:08 UTC (permalink / raw To: gentoo-dev On Mon, Nov 16, 2015 at 4:52 AM, Alexis Ballier <aballier@gentoo.org> wrote: > On Mon, 16 Nov 2015 10:29:43 +0100 > "Justin Lecher (jlec)" <jlec@gentoo.org> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 16/11/15 10:14, Alexis Ballier wrote: >> > Probably those that want to ban it should fix the(ir) tree so that >> > developers have no pain in bumping to eapi6? >> >> Versioned APIs are made to have incompatible changes. What do you like >> to see? > > deprecation warnings for some time or.. > Well, it sounds like you've received and understood your deprecation warning. :) EAPI5 won't be going away for a long time, and you can move to EAPI6 whenever you're ready. -- Rich ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1567619929.63486fef43c2e0dee3b4128db18fd1a6b4bf9381.tupone@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1567619929.63486fef43c2e0dee3b4128db18fd1a6b4bf9381.tupone@gentoo> @ 2019-09-04 18:59 ` Michał Górny 2019-09-04 22:30 ` David Seifert 2019-09-04 23:26 ` Thomas Deutschmann 0 siblings, 2 replies; 119+ messages in thread From: Michał Górny @ 2019-09-04 18:59 UTC (permalink / raw To: gentoo-dev, Alfredo Tupone, gentoo-commits [-- Attachment #1: Type: text/plain, Size: 850 bytes --] On Wed, 2019-09-04 at 18:00 +0000, Alfredo Tupone wrote: > commit: 63486fef43c2e0dee3b4128db18fd1a6b4bf9381 > Author: Tupone Alfredo <tupone <AT> gentoo <DOT> org> > AuthorDate: Wed Sep 4 17:58:49 2019 +0000 > Commit: Alfredo Tupone <tupone <AT> gentoo <DOT> org> > CommitDate: Wed Sep 4 17:58:49 2019 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63486fef > > ada.eclass: New eclass for dev-ada packages > > Signed-off-by: Alfredo Tupone <tupone <AT> gentoo.org> > > eclass/ada.eclass | 431 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 431 insertions(+) > Devmanual is pretty clear on the fact that *all* new eclasses require ml review *before* committing: https://devmanual.gentoo.org/eclass-writing/index.html -- Best regards, Michał Górny [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-04 18:59 ` Michał Górny @ 2019-09-04 22:30 ` David Seifert 2019-09-04 23:26 ` Thomas Deutschmann 1 sibling, 0 replies; 119+ messages in thread From: David Seifert @ 2019-09-04 22:30 UTC (permalink / raw To: gentoo-dev, Alfredo Tupone, gentoo-commits On Wed, 2019-09-04 at 20:59 +0200, Michał Górny wrote: > On Wed, 2019-09-04 at 18:00 +0000, Alfredo Tupone wrote: > > commit: 63486fef43c2e0dee3b4128db18fd1a6b4bf9381 > > Author: Tupone Alfredo <tupone <AT> gentoo <DOT> org> > > AuthorDate: Wed Sep 4 17:58:49 2019 +0000 > > Commit: Alfredo Tupone <tupone <AT> gentoo <DOT> org> > > CommitDate: Wed Sep 4 17:58:49 2019 +0000 > > URL: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63486fef > > > > ada.eclass: New eclass for dev-ada packages > > > > Signed-off-by: Alfredo Tupone <tupone <AT> gentoo.org> > > > > eclass/ada.eclass | 431 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 431 insertions(+) > > > > Devmanual is pretty clear on the fact that *all* new eclasses require > ml > review *before* committing: > > https://devmanual.gentoo.org/eclass-writing/index.html > Please revert. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-04 18:59 ` Michał Górny 2019-09-04 22:30 ` David Seifert @ 2019-09-04 23:26 ` Thomas Deutschmann 2019-09-05 4:02 ` Michał Górny 2019-09-06 4:02 ` Mike Gilbert 1 sibling, 2 replies; 119+ messages in thread From: Thomas Deutschmann @ 2019-09-04 23:26 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 1715 bytes --] Hi, On 2019-09-04 20:59, Michał Górny wrote: > Devmanual is pretty clear on the fact that *all* new eclasses require ml > ^^^^^^^^^^^^^^^^^^^^^^^ > review *before* committing: I am also working on a new eclass so I looked up details regarding what's needed to add a new eclass recently. I must say that I disagree that it's *pretty* clear. > Adding and Updating Eclasses > > Before committing a new eclass to the tree, it should be emailed > ^^^^^^ > to the gentoo-dev mailing list with a justification and a > proposed implementation. Do not skip this step — sometimes a > better implementation or an alternative which does not require a > new eclass will be suggested. > > Before updating [...] > > The exceptions to this rule are per-package eclasses. For > ^^^^^^^^^^^^^^^^^^^^ > example, the apache-2 eclass is only used by the www-servers/apache > package, and thus does not typically require changes to be emailed > for review. In my case I am working on a new mysql eclass to outsource pkg_config function which is shared at least between dev-db/mysql and dev-db/percona-server (and maybe dev-db/mariadb). For this new eclass I would say it's a "per-package" eclass and would probably have skipped mailing list review, too. If you want to make it clear, change "should" to "must" and maybe clarify per-package exception and limit to update case if you believe that really *all* *new* eclasses must be send to mailing list. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-04 23:26 ` Thomas Deutschmann @ 2019-09-05 4:02 ` Michał Górny 2019-09-05 13:14 ` Thomas Deutschmann 2019-09-06 4:02 ` Mike Gilbert 1 sibling, 1 reply; 119+ messages in thread From: Michał Górny @ 2019-09-05 4:02 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2035 bytes --] On Thu, 2019-09-05 at 01:26 +0200, Thomas Deutschmann wrote: > Hi, > > On 2019-09-04 20:59, Michał Górny wrote: > > Devmanual is pretty clear on the fact that *all* new eclasses require ml > > ^^^^^^^^^^^^^^^^^^^^^^^ > > review *before* committing: > > I am also working on a new eclass so I looked up details regarding > what's needed to add a new eclass recently. > > I must say that I disagree that it's *pretty* clear. > > > Adding and Updating Eclasses > > > > Before committing a new eclass to the tree, it should be emailed > > ^^^^^^ > > to the gentoo-dev mailing list with a justification and a > > proposed implementation. Do not skip this step — sometimes a > > better implementation or an alternative which does not require a > > new eclass will be suggested. > > > > Before updating [...] > > > > The exceptions to this rule are per-package eclasses. For > > ^^^^^^^^^^^^^^^^^^^^ > > example, the apache-2 eclass is only used by the www-servers/apache > > package, and thus does not typically require changes to be emailed > > for review. > > In my case I am working on a new mysql eclass to outsource pkg_config > function which is shared at least between dev-db/mysql and > dev-db/percona-server (and maybe dev-db/mariadb). > > For this new eclass I would say it's a "per-package" eclass and would > probably have skipped mailing list review, too. Everyone can skip as many paragraphs as they want, and then apply what's said later to something said way earlier. > > If you want to make it clear, change "should" to "must" and maybe > clarify per-package exception and limit to update case if you believe > that really *all* *new* eclasses must be send to mailing list. Submit a part. This is a community effort. Nitpicking and complaining doesn't make things better. Fixing them does. > > -- Best regards, Michał Górny [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-05 4:02 ` Michał Górny @ 2019-09-05 13:14 ` Thomas Deutschmann 2019-09-05 14:04 ` Gordon Pettey 2019-09-05 19:47 ` Michał Górny 0 siblings, 2 replies; 119+ messages in thread From: Thomas Deutschmann @ 2019-09-05 13:14 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 2020 bytes --] On 2019-09-05 06:02, Michał Górny wrote: >> In my case I am working on a new mysql eclass to outsource pkg_config >> function which is shared at least between dev-db/mysql and >> dev-db/percona-server (and maybe dev-db/mariadb). >> >> For this new eclass I would say it's a "per-package" eclass and would >> probably have skipped mailing list review, too. > > Everyone can skip as many paragraphs as they want, and then apply what's > said later to something said way earlier. Could you please stop adding any bad interpretation? That was a serious question. For you, it's pretty clear. I am showing you, that for me, it isn't pretty clear. When you believe I skipped important lines in my quote please outline what I have missed and I will take the blame. >> If you want to make it clear, change "should" to "must" and maybe >> clarify per-package exception and limit to update case if you believe >> that really *all* *new* eclasses must be send to mailing list. > > Submit a part. This is a community effort. Nitpicking and complaining > doesn't make things better. Fixing them does. Sure, but at the moment *you* are the one who are saying it's a MUST. I don't understand it that way and I am fine with my understanding that per-package eclasses *should* but *must not* get reviewed through mailing list. In other words I am asking you to show us where it's written that *all* *new* eclasses *must* get reviewed through mailing list. I cannot find something like that in current devmanual (the link you showed). Maybe I am still missing something after reading https://devmanual.gentoo.org/eclass-writing/ 3 times... In case I am not missing anything I suggested to improve devmanual in case you believe this should be a hard requirement. Because at the moment I don't believe it should be a hard requirement, *I* will not propose any changes. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-05 13:14 ` Thomas Deutschmann @ 2019-09-05 14:04 ` Gordon Pettey 2019-09-05 19:26 ` Kent Fredric 2019-09-05 19:47 ` Michał Górny 1 sibling, 1 reply; 119+ messages in thread From: Gordon Pettey @ 2019-09-05 14:04 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1035 bytes --] On Thu, Sep 5, 2019 at 8:15 AM Thomas Deutschmann <whissi@gentoo.org> wrote: > On 2019-09-05 06:02, Michał Górny wrote: > >> In my case I am working on a new mysql eclass to outsource pkg_config > >> function which is shared at least between dev-db/mysql and > >> dev-db/percona-server (and maybe dev-db/mariadb). > >> > >> For this new eclass I would say it's a "per-package" eclass and would > >> probably have skipped mailing list review, too. > > > > Everyone can skip as many paragraphs as they want, and then apply what's > > said later to something said way earlier. > > Could you please stop adding any bad interpretation? > > That was a serious question. For you, it's pretty clear. I am showing > you, that for me, it isn't pretty clear. When you believe I skipped > important lines in my quote please outline what I have missed and I will > take the blame. > You'll note the bit you quoted in defense of skipping review says "changes", and the bit about new eclasses says "do not skip this step". [-- Attachment #2: Type: text/html, Size: 1463 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-05 14:04 ` Gordon Pettey @ 2019-09-05 19:26 ` Kent Fredric 2019-09-05 19:28 ` James Le Cuirot 0 siblings, 1 reply; 119+ messages in thread From: Kent Fredric @ 2019-09-05 19:26 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 808 bytes --] On Thu, 5 Sep 2019 09:04:23 -0500 Gordon Pettey <petteyg359@gmail.com> wrote: > You'll note the bit you quoted in defense of skipping review says > "changes", and the bit about new eclasses says "do not skip this step". Emphasis added: ----- BEFORE committing a NEW eclass to the tree, it SHOULD be emailed to the gentoo-dev mailing list with a justification and a proposed implementation. DO NOT SKIP this step — sometimes a better implementation or an alternative which does not require a new eclass will be suggested. ----- If its mandatory, it must say "MUST" not "SHOULD", SHOULD is a suggestion, following a suggestion with an imperative just adds predictable confusion. Either fix the "should", or drop the "DO NOT SKIP". Otherwise you're just giving mixed messages. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-05 19:26 ` Kent Fredric @ 2019-09-05 19:28 ` James Le Cuirot 0 siblings, 0 replies; 119+ messages in thread From: James Le Cuirot @ 2019-09-05 19:28 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 998 bytes --] On Fri, 6 Sep 2019 07:26:42 +1200 Kent Fredric <kentnl@gentoo.org> wrote: > On Thu, 5 Sep 2019 09:04:23 -0500 > Gordon Pettey <petteyg359@gmail.com> wrote: > > > You'll note the bit you quoted in defense of skipping review says > > "changes", and the bit about new eclasses says "do not skip this step". > > Emphasis added: > > ----- > BEFORE committing a NEW eclass to the tree, it SHOULD be emailed to the > gentoo-dev mailing list with a justification and a proposed > implementation. DO NOT SKIP this step — sometimes a better > implementation or an alternative which does not require a new eclass > will be suggested. > ----- > > > If its mandatory, it must say "MUST" not "SHOULD", SHOULD is a > suggestion, following a suggestion with an imperative just adds > predictable confusion. > > Either fix the "should", or drop the "DO NOT SKIP". > > Otherwise you're just giving mixed messages. +1 -- James Le Cuirot (chewi) Gentoo Linux Developer [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-05 13:14 ` Thomas Deutschmann 2019-09-05 14:04 ` Gordon Pettey @ 2019-09-05 19:47 ` Michał Górny 2019-09-05 19:49 ` Michael Everitt 2019-09-05 20:08 ` Kent Fredric 1 sibling, 2 replies; 119+ messages in thread From: Michał Górny @ 2019-09-05 19:47 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2448 bytes --] On Thu, 2019-09-05 at 15:14 +0200, Thomas Deutschmann wrote: > On 2019-09-05 06:02, Michał Górny wrote: > > > In my case I am working on a new mysql eclass to outsource pkg_config > > > function which is shared at least between dev-db/mysql and > > > dev-db/percona-server (and maybe dev-db/mariadb). > > > > > > For this new eclass I would say it's a "per-package" eclass and would > > > probably have skipped mailing list review, too. > > > > Everyone can skip as many paragraphs as they want, and then apply what's > > said later to something said way earlier. > > Could you please stop adding any bad interpretation? > > That was a serious question. For you, it's pretty clear. I am showing > you, that for me, it isn't pretty clear. When you believe I skipped > important lines in my quote please outline what I have missed and I will > take the blame. > > > > > If you want to make it clear, change "should" to "must" and maybe > > > clarify per-package exception and limit to update case if you believe > > > that really *all* *new* eclasses must be send to mailing list. > > > > Submit a part. This is a community effort. Nitpicking and complaining > > doesn't make things better. Fixing them does. > > Sure, but at the moment *you* are the one who are saying it's a MUST. I > don't understand it that way and I am fine with my understanding that > per-package eclasses *should* but *must not* get reviewed through > mailing list. In other words I am asking you to show us where it's > written that *all* *new* eclasses *must* get reviewed through mailing > list. I cannot find something like that in current devmanual (the link > you showed). > > Maybe I am still missing something after reading > https://devmanual.gentoo.org/eclass-writing/ 3 times... > > In case I am not missing anything I suggested to improve devmanual in > case you believe this should be a hard requirement. Because at the > moment I don't believe it should be a hard requirement, *I* will not > propose any changes. > So to summarize, instead of working together in order to follow a well- established policy, you prefer to do whatever you find convenient at the moment, as long as you justify it by finding some document whose wording does not perfectly prevent you from bending the policy? Yes, that sounds like a very good attitude for a Council member. -- Best regards, Michał Górny [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-05 19:47 ` Michał Górny @ 2019-09-05 19:49 ` Michael Everitt 2019-09-05 20:08 ` Kent Fredric 1 sibling, 0 replies; 119+ messages in thread From: Michael Everitt @ 2019-09-05 19:49 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 2478 bytes --] On 05/09/19 20:47, Michał Górny wrote: > On Thu, 2019-09-05 at 15:14 +0200, Thomas Deutschmann wrote: >> On 2019-09-05 06:02, Michał Górny wrote: >>>> In my case I am working on a new mysql eclass to outsource pkg_config >>>> function which is shared at least between dev-db/mysql and >>>> dev-db/percona-server (and maybe dev-db/mariadb). >>>> >>>> For this new eclass I would say it's a "per-package" eclass and would >>>> probably have skipped mailing list review, too. >>> Everyone can skip as many paragraphs as they want, and then apply what's >>> said later to something said way earlier. >> Could you please stop adding any bad interpretation? >> >> That was a serious question. For you, it's pretty clear. I am showing >> you, that for me, it isn't pretty clear. When you believe I skipped >> important lines in my quote please outline what I have missed and I will >> take the blame. >> >> >>>> If you want to make it clear, change "should" to "must" and maybe >>>> clarify per-package exception and limit to update case if you believe >>>> that really *all* *new* eclasses must be send to mailing list. >>> Submit a part. This is a community effort. Nitpicking and complaining >>> doesn't make things better. Fixing them does. >> Sure, but at the moment *you* are the one who are saying it's a MUST. I >> don't understand it that way and I am fine with my understanding that >> per-package eclasses *should* but *must not* get reviewed through >> mailing list. In other words I am asking you to show us where it's >> written that *all* *new* eclasses *must* get reviewed through mailing >> list. I cannot find something like that in current devmanual (the link >> you showed). >> >> Maybe I am still missing something after reading >> https://devmanual.gentoo.org/eclass-writing/ 3 times... >> >> In case I am not missing anything I suggested to improve devmanual in >> case you believe this should be a hard requirement. Because at the >> moment I don't believe it should be a hard requirement, *I* will not >> propose any changes. >> > So to summarize, instead of working together in order to follow a well- > established policy, you prefer to do whatever you find convenient > at the moment, as long as you justify it by finding some document whose > wording does not perfectly prevent you from bending the policy? Yes, > that sounds like a very good attitude for a Council member. > Pot meet Kettle .. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-05 19:47 ` Michał Górny 2019-09-05 19:49 ` Michael Everitt @ 2019-09-05 20:08 ` Kent Fredric 2019-09-05 20:16 ` Michał Górny 1 sibling, 1 reply; 119+ messages in thread From: Kent Fredric @ 2019-09-05 20:08 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 717 bytes --] On Thu, 05 Sep 2019 21:47:11 +0200 Michał Górny <mgorny@gentoo.org> wrote: > So to summarize, instead of working together in order to follow a well- > established policy, You're reading it wrong. If its "established policy", dev manual must reflect that. If the dev-manual writes "should" in one place, and implies "must" in another for a same thing, then either: - The dev manual needs to be fixed - The policy is not as you suggest it is. If the dev-manual is written correctly for the policy, then I expect he is saying he'll follow it. But as per the way the dev manual is written, he arguably *is* following policy. Stop taking the line of assuming he's trying to be belligerent. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-05 20:08 ` Kent Fredric @ 2019-09-05 20:16 ` Michał Górny 2019-09-05 22:47 ` Thomas Deutschmann 0 siblings, 1 reply; 119+ messages in thread From: Michał Górny @ 2019-09-05 20:16 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1231 bytes --] On Fri, 2019-09-06 at 08:08 +1200, Kent Fredric wrote: > On Thu, 05 Sep 2019 21:47:11 +0200 > Michał Górny <mgorny@gentoo.org> wrote: > > > So to summarize, instead of working together in order to follow a well- > > established policy, > > You're reading it wrong. If its "established policy", dev manual must > reflect that. > > If the dev-manual writes "should" in one place, and implies "must" in > another for a same thing, then either: > > - The dev manual needs to be fixed > - The policy is not as you suggest it is. > > If the dev-manual is written correctly for the policy, then I expect he > is saying he'll follow it. We've already established that the wording in devmanual is unfortunate, and I've asked him to submit a patch. It would be really nice if more than three developers cared to actually work on devmanual which is probably the most important document for devs. > But as per the way the dev manual is written, he arguably *is* > following policy. > > Stop taking the line of assuming he's trying to be belligerent. He says explicitly that he is against fixing devmanual because he likes the way he can abuse it right now. -- Best regards, Michał Górny [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-05 20:16 ` Michał Górny @ 2019-09-05 22:47 ` Thomas Deutschmann 2019-09-06 3:45 ` Mike Gilbert 2019-09-06 5:49 ` Michał Górny 0 siblings, 2 replies; 119+ messages in thread From: Thomas Deutschmann @ 2019-09-05 22:47 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 1569 bytes --] On 2019-09-05 22:16, Michał Górny wrote: >> But as per the way the dev manual is written, he arguably *is* >> following policy. >> >> Stop taking the line of assuming he's trying to be belligerent. > > He says explicitly that he is against fixing devmanual because he likes > the way he can abuse it right now. You are the only one adding _abuse_ here. Stop that, thanks. When I replied to your mail I was just asking... nothing more. I don't understand why you are reading so much into it. But yes, I like the current exception for "per-package" eclasses like I am concerned that a review requirement would cause a significant delay: Back to my example, imagine we would move pkg_config to new mysql eclass. If we would bump mysql/percona-server/mariadb package and will receive bug reports later because upstream changed something causing pkg_config to fail we would now have to propose a patch, wait 48 hours... i.e. package would be broken for ~72 hours just because of a policy I don't reject in general (yes, I like reviews) but where I think exceptions must be possible. So for my understanding this is not about 'fixing' devmanual. It's about *changing* devmanual which I *just* pointed out. But whoever will propose changing devmanual should support such a change because he/she will probably have to argue for that change. Something I cannot do when I like status quo like I do currently or have concerns. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-05 22:47 ` Thomas Deutschmann @ 2019-09-06 3:45 ` Mike Gilbert 2019-09-06 6:35 ` Alfredo Tupone 2019-09-06 5:49 ` Michał Górny 1 sibling, 1 reply; 119+ messages in thread From: Mike Gilbert @ 2019-09-06 3:45 UTC (permalink / raw To: Gentoo Dev On Thu, Sep 5, 2019 at 6:47 PM Thomas Deutschmann <whissi@gentoo.org> wrote: > > On 2019-09-05 22:16, Michał Górny wrote: > >> But as per the way the dev manual is written, he arguably *is* > >> following policy. > >> > >> Stop taking the line of assuming he's trying to be belligerent. > > > > He says explicitly that he is against fixing devmanual because he likes > > the way he can abuse it right now. > > You are the only one adding _abuse_ here. Stop that, thanks. When I > replied to your mail I was just asking... nothing more. I don't > understand why you are reading so much into it. The devmanual o clearly indicates that an email to gentoo-dev is strongly preferred. I don't see any reason why tupone could not have done this. You seem to be trying to take this opportunity to prove some loosely related point. > But yes, I like the current exception for "per-package" eclasses like I > am concerned that a review requirement would cause a significant delay: > > Back to my example, imagine we would move pkg_config to new mysql > eclass. If we would bump mysql/percona-server/mariadb package and will > receive bug reports later because upstream changed something causing > pkg_config to fail we would now have to propose a patch, wait 48 > hours... i.e. package would be broken for ~72 hours just because of a > policy I don't reject in general (yes, I like reviews) but where I think > exceptions must be possible. This argument is stupid. If you need to push a critical bug fix, then do it. Nobody will fault you for it. This clearly does not apply to ada.eclass. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-06 3:45 ` Mike Gilbert @ 2019-09-06 6:35 ` Alfredo Tupone 0 siblings, 0 replies; 119+ messages in thread From: Alfredo Tupone @ 2019-09-06 6:35 UTC (permalink / raw To: gentoo-dev On 23:45 Thu 05 Sep , Mike Gilbert wrote: > On Thu, Sep 5, 2019 at 6:47 PM Thomas Deutschmann <whissi@gentoo.org> wrote: > > > > On 2019-09-05 22:16, Michał Górny wrote: > > >> But as per the way the dev manual is written, he arguably *is* > > >> following policy. > > >> > > >> Stop taking the line of assuming he's trying to be belligerent. > > > > > > He says explicitly that he is against fixing devmanual because he likes > > > the way he can abuse it right now. > > > > You are the only one adding _abuse_ here. Stop that, thanks. When I > > replied to your mail I was just asking... nothing more. I don't > > understand why you are reading so much into it. > > The devmanual o clearly indicates that an email to gentoo-dev is > strongly preferred. I don't see any reason why tupone could not have > done this. > > You seem to be trying to take this opportunity to prove some loosely > related point. > > > But yes, I like the current exception for "per-package" eclasses like I > > am concerned that a review requirement would cause a significant delay: > > > > Back to my example, imagine we would move pkg_config to new mysql > > eclass. If we would bump mysql/percona-server/mariadb package and will > > receive bug reports later because upstream changed something causing > > pkg_config to fail we would now have to propose a patch, wait 48 > > hours... i.e. package would be broken for ~72 hours just because of a > > policy I don't reject in general (yes, I like reviews) but where I think > > exceptions must be possible. > > This argument is stupid. If you need to push a critical bug fix, then > do it. Nobody will fault you for it. > > This clearly does not apply to ada.eclass. > I am going just to explain the reason why I did not ask ml about review the first time. 1) ada.eclass is copied from python-single-r1 eclass with s/PYTHON/ADA/ and removing pieces that I don't need 2) The eclass is only for packages that I mantains exclusively and they are not such a great number The eclass is an effort to avoid in the future the same problems raised from qa-check All comes from a suggestion to use USE_EXPAND for gnat_2016 gnat_2017 ... My opinion is that the ml review should be mandatory only for new eclasses that are meant to be used by all the tree or by a great number of packages (>= 100 ?) However, as stated in the email I reverted my changes and add the eclass to the ml. Then, what a review means, when it is approved or denied, I will try to learn Alfredo ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-05 22:47 ` Thomas Deutschmann 2019-09-06 3:45 ` Mike Gilbert @ 2019-09-06 5:49 ` Michał Górny 1 sibling, 0 replies; 119+ messages in thread From: Michał Górny @ 2019-09-06 5:49 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1903 bytes --] On Fri, 2019-09-06 at 00:47 +0200, Thomas Deutschmann wrote: > On 2019-09-05 22:16, Michał Górny wrote: > > > But as per the way the dev manual is written, he arguably *is* > > > following policy. > > > > > > Stop taking the line of assuming he's trying to be belligerent. > > > > He says explicitly that he is against fixing devmanual because he likes > > the way he can abuse it right now. > > You are the only one adding _abuse_ here. Stop that, thanks. When I > replied to your mail I was just asking... nothing more. I don't > understand why you are reading so much into it. > > But yes, I like the current exception for "per-package" eclasses like I > am concerned that a review requirement would cause a significant delay: > > Back to my example, imagine we would move pkg_config to new mysql > eclass. If we would bump mysql/percona-server/mariadb package and will > receive bug reports later because upstream changed something causing > pkg_config to fail we would now have to propose a patch, wait 48 > hours... i.e. package would be broken for ~72 hours just because of a > policy I don't reject in general (yes, I like reviews) but where I think > exceptions must be possible. Are you really saying that if you push buggy eclass (without review?), then you need to push yet another eclass to fix it? If so, then it looks like something is really wrong with your workflow. > So for my understanding this is not about 'fixing' devmanual. It's about > *changing* devmanual which I *just* pointed out. But whoever will > propose changing devmanual should support such a change because he/she > will probably have to argue for that change. Something I cannot do when > I like status quo like I do currently or have concerns. So you don't believe in civil duty over your private interest. Okay, understood. -- Best regards, Michał Górny [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-09-04 23:26 ` Thomas Deutschmann 2019-09-05 4:02 ` Michał Górny @ 2019-09-06 4:02 ` Mike Gilbert 1 sibling, 0 replies; 119+ messages in thread From: Mike Gilbert @ 2019-09-06 4:02 UTC (permalink / raw To: Gentoo Dev On Wed, Sep 4, 2019 at 7:26 PM Thomas Deutschmann <whissi@gentoo.org> wrote: > If you want to make it clear, change "should" to "must" and maybe > clarify per-package exception and limit to update case if you believe > that really *all* *new* eclasses must be send to mailing list. As a native English speaker/writer, I find this "should" versus "must" argument very tedious. If a technical document says I "should" do something, and I don't do it, I probably have very good reason for not doing it and should be able to easily explain that reason. There's nothing wrong with that, and calling it out on a mailing list is entirely appropriate. If a technical document says I "must" do something, I take that somewhat more seriously, and I expect bad things will happen if I go against it. In the case of Gentoo, I would expect a revert with no questions asked if the procedure is not followed. In either case, it's clear that the advice given in the document is something I should pay attention to. ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1564451381.6f680e4fe73925ae130343e02adb416cb799ce7d.mattst88@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1564451381.6f680e4fe73925ae130343e02adb416cb799ce7d.mattst88@gentoo> @ 2019-07-30 5:20 ` Michał Górny 2019-07-30 5:29 ` Matt Turner 0 siblings, 1 reply; 119+ messages in thread From: Michał Górny @ 2019-07-30 5:20 UTC (permalink / raw To: gentoo-dev; +Cc: Matt Turner, qa [-- Attachment #1: Type: text/plain, Size: 2267 bytes --] On Tue, 2019-07-30 at 01:49 +0000, Matt Turner wrote: > commit: 6f680e4fe73925ae130343e02adb416cb799ce7d > Author: Chris Mayo <aklhfex <AT> gmail <DOT> com> > AuthorDate: Fri Jul 26 18:48:13 2019 +0000 > Commit: Matt Turner <mattst88 <AT> gentoo <DOT> org> > CommitDate: Tue Jul 30 01:49:41 2019 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f680e4f > > virtualx.eclass: Fix no display for an emerge following a failure > > If using GNOME GDM, X is started on DISPLAY :0 but a lock file > /tmp/.X1024-lock is created instead of /tmp/.X0-lock. > virtx() will initially set XDISPLAY to 0 and attempt to start Xvfb on > DISPLAY :0 which fails but DISPLAY :1 (and greater) is not attempted if > a previous emerge left /tmp/.X1-lock behind. > > Closes: https://bugs.gentoo.org/690778 > Signed-off-by: Chris Mayo <aklhfex <AT> gmail.com> > Signed-off-by: Matt Turner <mattst88 <AT> gentoo.org> > > eclass/virtualx.eclass | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass > index fb6a867a35c..40eeea5463b 100644 > --- a/eclass/virtualx.eclass > +++ b/eclass/virtualx.eclass > @@ -1,4 +1,4 @@ > -# Copyright 1999-2018 Gentoo Foundation > +# Copyright 1999-2019 Gentoo Authors > # Distributed under the terms of the GNU General Public License v2 > > # @ECLASS: virtualx.eclass > @@ -178,7 +178,10 @@ virtx() { > # Xvfb is started, else bump the display number > # > # Azarah - 5 May 2002 > - XDISPLAY=$(i=0; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; echo ${i}) > + # GNOME GDM may have started X on DISPLAY :0 with a > + # lock file /tmp/.X1024-lock, therefore start the search at 1. > + # Else a leftover /tmp/.X1-lock will prevent finding an available display. > + XDISPLAY=$(i=1; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; echo ${i}) > debug-print "${FUNCNAME}: XDISPLAY=${XDISPLAY}" > > # We really do not want SANDBOX enabled here Isn't this a cheap hack that doesn't fix the underlying issue but shifts the problem into hopefully-won't-happen-this-time? Also, why are you skipping mailing list review for eclass changes? -- Best regards, Michał Górny [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2019-07-30 5:20 ` Michał Górny @ 2019-07-30 5:29 ` Matt Turner 0 siblings, 0 replies; 119+ messages in thread From: Matt Turner @ 2019-07-30 5:29 UTC (permalink / raw To: Michał Górny; +Cc: gentoo development, qa On Mon, Jul 29, 2019 at 10:20 PM Michał Górny <mgorny@gentoo.org> wrote: > > On Tue, 2019-07-30 at 01:49 +0000, Matt Turner wrote: > > commit: 6f680e4fe73925ae130343e02adb416cb799ce7d > > Author: Chris Mayo <aklhfex <AT> gmail <DOT> com> > > AuthorDate: Fri Jul 26 18:48:13 2019 +0000 > > Commit: Matt Turner <mattst88 <AT> gentoo <DOT> org> > > CommitDate: Tue Jul 30 01:49:41 2019 +0000 > > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f680e4f > > > > virtualx.eclass: Fix no display for an emerge following a failure > > > > If using GNOME GDM, X is started on DISPLAY :0 but a lock file > > /tmp/.X1024-lock is created instead of /tmp/.X0-lock. > > virtx() will initially set XDISPLAY to 0 and attempt to start Xvfb on > > DISPLAY :0 which fails but DISPLAY :1 (and greater) is not attempted if > > a previous emerge left /tmp/.X1-lock behind. > > > > Closes: https://bugs.gentoo.org/690778 > > Signed-off-by: Chris Mayo <aklhfex <AT> gmail.com> > > Signed-off-by: Matt Turner <mattst88 <AT> gentoo.org> > > > > eclass/virtualx.eclass | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass > > index fb6a867a35c..40eeea5463b 100644 > > --- a/eclass/virtualx.eclass > > +++ b/eclass/virtualx.eclass > > @@ -1,4 +1,4 @@ > > -# Copyright 1999-2018 Gentoo Foundation > > +# Copyright 1999-2019 Gentoo Authors > > # Distributed under the terms of the GNU General Public License v2 > > > > # @ECLASS: virtualx.eclass > > @@ -178,7 +178,10 @@ virtx() { > > # Xvfb is started, else bump the display number > > # > > # Azarah - 5 May 2002 > > - XDISPLAY=$(i=0; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; echo ${i}) > > + # GNOME GDM may have started X on DISPLAY :0 with a > > + # lock file /tmp/.X1024-lock, therefore start the search at 1. > > + # Else a leftover /tmp/.X1-lock will prevent finding an available display. > > + XDISPLAY=$(i=1; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; echo ${i}) > > debug-print "${FUNCNAME}: XDISPLAY=${XDISPLAY}" > > > > # We really do not want SANDBOX enabled here > > Isn't this a cheap hack that doesn't fix the underlying issue but shifts > the problem into hopefully-won't-happen-this-time? Yes, but given that the prior code was a cheap hack as well (from 2002, no less!) and has worked out well enough for 17 years that no one has reported problems with it until now, I don't think it's critical to make it bullet-proof. Of course I'm happy to accept patches. > Also, why are you skipping mailing list review for eclass changes? Ah, you are right. My apologies. ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1526675772.d780c05e4459175eb314c82de9f3b998e2b4fc6e.asturm@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1526675772.d780c05e4459175eb314c82de9f3b998e2b4fc6e.asturm@gentoo> @ 2018-05-18 21:53 ` Michał Górny 0 siblings, 0 replies; 119+ messages in thread From: Michał Górny @ 2018-05-18 21:53 UTC (permalink / raw To: gentoo-dev, Andreas Sturmlechner W dniu pią, 18.05.2018 o godzinie 20∶36 +0000, użytkownik Andreas Sturmlechner napisał: > commit: d780c05e4459175eb314c82de9f3b998e2b4fc6e > Author: Andreas Sturmlechner <asturm <AT> gentoo <DOT> org> > AuthorDate: Thu May 10 20:42:15 2018 +0000 > Commit: Andreas Sturmlechner <asturm <AT> gentoo <DOT> org> > CommitDate: Fri May 18 20:36:12 2018 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d780c05e > > cmake-utils.eclass: Switch to eapi7-ver > > eclass/cmake-utils.eclass | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass > index 3302f27608b..cbce280625e 100644 > --- a/eclass/cmake-utils.eclass > +++ b/eclass/cmake-utils.eclass > @@ -109,11 +109,11 @@ case ${EAPI} in > *) die "EAPI=${EAPI:-0} is not supported" ;; > esac > > -inherit toolchain-funcs ninja-utils flag-o-matic multiprocessing versionator xdg-utils > +inherit toolchain-funcs ninja-utils flag-o-matic multiprocessing xdg-utils > > case ${EAPI} in > 7) ;; > - *) inherit eutils multilib ;; > + *) inherit eapi7-ver eutils multilib ;; > esac > > EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install > @@ -512,7 +512,7 @@ cmake-utils_src_configure() { > # we need to add "<INCLUDES>" > local includes= > if [[ ${PN} == cmake ]] ; then > - if $(version_is_at_least 3.4.0 $(get_version_component_range 1-3 ${PV})) ; then > + if $(version_is_at_least 3.4.0 $(ver_cut 1-3 ${PV})) ; then One of the reasons we do mailing list reviews of widely used eclasses is to let people tell you that you've left 'version_is_at_least' here. > includes="<INCLUDES>" > fi > elif ROOT=/ has_version \>=dev-util/cmake-3.4.0_rc1 ; then > -- Best regards, Michał Górny ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1515158020.1e09cba657ccb2b8e6fbcbeb28c5c593da2127eb.polynomial-c@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1515158020.1e09cba657ccb2b8e6fbcbeb28c5c593da2127eb.polynomial-c@gentoo> @ 2018-01-05 13:36 ` Michał Górny 0 siblings, 0 replies; 119+ messages in thread From: Michał Górny @ 2018-01-05 13:36 UTC (permalink / raw To: gentoo-dev, Lars Wendler, gentoo-commits W dniu pią, 05.01.2018 o godzinie 13∶13 +0000, użytkownik Lars Wendler napisał: > commit: 1e09cba657ccb2b8e6fbcbeb28c5c593da2127eb > Author: Gary Macindoe <gary <AT> garymacindoe <DOT> co <DOT> uk> > AuthorDate: Thu Sep 28 21:32:34 2017 +0000 > Commit: Lars Wendler <polynomial-c <AT> gentoo <DOT> org> > CommitDate: Fri Jan 5 13:13:40 2018 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e09cba6 > > Fix handling of multiple CDs > > Closes: https://github.com/gentoo/gentoo/pull/5818 > > eclass/cdrom.eclass | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass > index 47e2c6342e0..7b0eb9c6c3b 100644 > --- a/eclass/cdrom.eclass > +++ b/eclass/cdrom.eclass > @@ -71,7 +71,12 @@ fi > # eclass, see that function's description. > cdrom_get_cds() { > unset CDROM_SET > - export CDROM_CURRENT_CD=0 CDROM_CHECKS=( "${@}" ) > + export CDROM_CURRENT_CD=0 > + export CDROM_NUM_CDS="${#}" > + local i > + for i in $(seq ${#}); do > + export CDROM_CHECK_${i}="${!i}" > + done Please fix the indentation. > > # If the user has set CD_ROOT or CD_ROOT_1, don't bother informing > # them about which discs are needed as they presumably already know. > @@ -190,7 +195,8 @@ cdrom_load_next_cd() { > local i cdset > : CD_ROOT_${CDROM_CURRENT_CD} > export CDROM_ROOT=${CD_ROOT:-${!_}} > - IFS=: read -r -a cdset -d "" <<< "${CDROM_CHECKS[$((${CDROM_CURRENT_CD} - 1))]}" > + local var="CDROM_CHECK_${CDROM_CURRENT_CD}" > + IFS=: read -r -a cdset -d "" <<< "${!var}" > > for i in $(seq ${CDROM_SET:-0} ${CDROM_SET:-$((${#cdset[@]} - 1))}); do > local f=${cdset[${i}]} point= node= fs= opts= > @@ -222,7 +228,7 @@ cdrom_load_next_cd() { > fi > > if [[ ${showedmsg} -eq 0 ]] ; then > - if [[ ${#CDROM_CHECKS[@]} -eq 1 ]] ; then > + if [[ ${CDROM_NUM_CDS} -eq 1 ]] ; then > einfo "Please insert+mount the ${CDROM_NAME:-CD for ${PN}} now !" > else > local var="CDROM_NAME_${CDROM_CURRENT_CD}" > This looks like a major change which also pretty much reverts the direction the previous (ml-reviewed) patches took. As such, it would be really desirable to post it for review instead of stealthily committing to an eclass which -- as far as metadata says -- you aren't even maintainer of. -- Best regards, Michał Górny ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1494961831.d1b05bcf81e5058c20615179fb83a90c45daa487.vapier@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1494961831.d1b05bcf81e5058c20615179fb83a90c45daa487.vapier@gentoo> @ 2017-05-16 19:20 ` Michał Górny 2017-05-16 19:36 ` Fabian Groffen 2017-05-21 17:46 ` Raymond Jennings 0 siblings, 2 replies; 119+ messages in thread From: Michał Górny @ 2017-05-16 19:20 UTC (permalink / raw To: gentoo-dev, Mike Frysinger; +Cc: qa [-- Attachment #1: Type: text/plain, Size: 1964 bytes --] Mike, On wto, 2017-05-16 at 19:10 +0000, Mike Frysinger wrote: > commit: d1b05bcf81e5058c20615179fb83a90c45daa487 > Author: Mike Frysinger <vapier <AT> chromium <DOT> org> > AuthorDate: Tue May 9 02:34:53 2017 +0000 > Commit: Mike Frysinger <vapier <AT> gentoo <DOT> org> > CommitDate: Tue May 16 19:10:31 2017 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d1b05bcf > > python-utils-r1.eclass: add more info to stub python wrappers > > The short terse error messages here are not easy to track down. Add > a few more details so people can figure out what's going wrong faster. > > eclass/python-utils-r1.eclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass > index c1349ff277b..0bf7e7ec1a3 100644 > --- a/eclass/python-utils-r1.eclass > +++ b/eclass/python-utils-r1.eclass > @@ -1041,7 +1041,7 @@ python_wrapper_setup() { > for x in "${nonsupp[@]}"; do > cat >"${workdir}"/bin/${x} <<-_EOF_ || die > #!/bin/sh > - echo "${x} is not supported by ${EPYTHON}" >&2 > + echo "${ECLASS}: ${FUNCNAME}: ${x} is not supported by ${EPYTHON} (PYTHON_COMPAT)" >&2 > exit 127 > _EOF_ > chmod +x "${workdir}"/bin/${x} || die I would really appreciate if you cared to follow procedures for eclass changes. Most notably, if you at least bothered to either ping us *or* sent the patch to the mailing list beforehand. This eclass is used by almost 6700 ebuilds. I am trying *hard* to commit changes in large patchsets to reduce cache updates. Of course it is all pointless if a random Mike Frysinger, developer on special rights, goes ahead and commits whatever he wants to whatever eclasses he wants to commit to, whatever time he pleases. Normally, I would revert it but I don't feel like causing third huge cache update today. -- Best regards, Michał Górny [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 963 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2017-05-16 19:20 ` Michał Górny @ 2017-05-16 19:36 ` Fabian Groffen 2017-05-21 14:02 ` Kent Fredric 2017-05-21 17:46 ` Raymond Jennings 1 sibling, 1 reply; 119+ messages in thread From: Fabian Groffen @ 2017-05-16 19:36 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 464 bytes --] On 16-05-2017 21:20:01 +0200, Michał Górny wrote: > This eclass is used by almost 6700 ebuilds. I am trying *hard* to commit > changes in large patchsets to reduce cache updates. [snip] > Normally, I would revert it but I don't feel like causing third huge > cache update today. What is the actual problem with that? Hardware or more deltas to download by users? Just wondering. Thanks, Fabian -- Fabian Groffen Gentoo on a different level [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2017-05-16 19:36 ` Fabian Groffen @ 2017-05-21 14:02 ` Kent Fredric 2017-05-21 14:46 ` Martin Vaeth 0 siblings, 1 reply; 119+ messages in thread From: Kent Fredric @ 2017-05-21 14:02 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 376 bytes --] On Tue, 16 May 2017 21:36:15 +0200 Fabian Groffen <grobian@gentoo.org> wrote: > Hardware or more deltas to > download by users? Just wondering. Both. - End users using git end up having to do massive metadata-updates. - Infra needs to have massive hits to metadata regeneration - End users using rsync have to fetch large deltas So its all-round sadness :( [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2017-05-21 14:02 ` Kent Fredric @ 2017-05-21 14:46 ` Martin Vaeth 2017-05-21 16:29 ` William Hubbs 0 siblings, 1 reply; 119+ messages in thread From: Martin Vaeth @ 2017-05-21 14:46 UTC (permalink / raw To: gentoo-dev Kent Fredric <kentnl@gentoo.org> wrote: > Fabian Groffen <grobian@gentoo.org> wrote: > >> Hardware or more deltas to >> download by users? Just wondering. > > Both. > > - End users using git end up having to do massive metadata-updates. > - Infra needs to have massive hits to metadata regeneration > - End users using rsync have to fetch large deltas - Users using git repositories with pre-generated metadata have to download/store much more history data ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2017-05-21 14:46 ` Martin Vaeth @ 2017-05-21 16:29 ` William Hubbs 2017-05-21 17:34 ` Michał Górny 0 siblings, 1 reply; 119+ messages in thread From: William Hubbs @ 2017-05-21 16:29 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 685 bytes --] On Sun, May 21, 2017 at 02:46:54PM +0000, Martin Vaeth wrote: > Kent Fredric <kentnl@gentoo.org> wrote: > > Fabian Groffen <grobian@gentoo.org> wrote: > > > >> Hardware or more deltas to > >> download by users? Just wondering. > > > > Both. > > > > - End users using git end up having to do massive metadata-updates. > > - Infra needs to have massive hits to metadata regeneration > > - End users using rsync have to fetch large deltas > > - Users using git repositories with pre-generated metadata have to > download/store much more history data If this is such a big problem, maybe we should be discussing how to redesign things to improve it? William [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2017-05-21 16:29 ` William Hubbs @ 2017-05-21 17:34 ` Michał Górny 2017-05-21 18:18 ` Martin Vaeth 2017-05-21 19:32 ` Kent Fredric 0 siblings, 2 replies; 119+ messages in thread From: Michał Górny @ 2017-05-21 17:34 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 883 bytes --] On nie, 2017-05-21 at 11:29 -0500, William Hubbs wrote: > On Sun, May 21, 2017 at 02:46:54PM +0000, Martin Vaeth wrote: > > Kent Fredric <kentnl@gentoo.org> wrote: > > > Fabian Groffen <grobian@gentoo.org> wrote: > > > > > > > Hardware or more deltas to > > > > download by users? Just wondering. > > > > > > Both. > > > > > > - End users using git end up having to do massive metadata-updates. > > > - Infra needs to have massive hits to metadata regeneration > > > - End users using rsync have to fetch large deltas > > > > - Users using git repositories with pre-generated metadata have to > > download/store much more history data > > If this is such a big problem, maybe we should be discussing how to > redesign things to improve it? > Like, by not using eclasses and instead inlining all the stuff? -- Best regards, Michał Górny [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 988 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2017-05-21 17:34 ` Michał Górny @ 2017-05-21 18:18 ` Martin Vaeth 2017-05-21 19:32 ` Kent Fredric 1 sibling, 0 replies; 119+ messages in thread From: Martin Vaeth @ 2017-05-21 18:18 UTC (permalink / raw To: gentoo-dev Michał Górny <mgorny@gentoo.org> wrote: >> If this is such a big problem, maybe we should be discussing how to >> redesign things to improve it? > > Like, by not using eclasses and instead inlining all the stuff? There are other ways. One way to mitigate the problem might be to require that eclasses contain some # @VERSION: major.minor-revision line and that the metadata cache of an ebuild contains that version number (or at least the major component of it) instead of an md5 sum. Then the commiter of the eclass has full control whether a metadata regeneration will happen or not: For trivial changes (see below), the committer simply does not increase that version number (or increase only minor-revision), and one could agree that a rebuild of the metadata only happens if the major version number of an eclass changes. By "trivial changes" I mean in this connection not only changes in comments but also minor changes in functionality or even in the API: The only strict requirement is that the major version has to increase if the eclass change can induce a change in the metadata of some ebuild using it (e.g. if a value printed by some function changes which might involve IUSE, REQUIRED_USE, DEPEND, ...) ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2017-05-21 17:34 ` Michał Górny 2017-05-21 18:18 ` Martin Vaeth @ 2017-05-21 19:32 ` Kent Fredric 2017-05-21 20:38 ` M. J. Everitt 2017-05-21 23:28 ` M. J. Everitt 1 sibling, 2 replies; 119+ messages in thread From: Kent Fredric @ 2017-05-21 19:32 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 571 bytes --] On Sun, 21 May 2017 19:34:26 +0200 Michał Górny <mgorny@gentoo.org> wrote: > Like, by not using eclasses and instead inlining all the stuff? I'd personally suggest we endeavour towards making systems in place so that the performance overheads of metadata generation is much lower, to the point it can be done efficiently without needing cache provisioning. But I'd also like a pony. ( I have ideas using daemons, inotify, and persistent databases as the primary metadata layer instead of millions of files, but they're all too complicated and hard ) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2017-05-21 19:32 ` Kent Fredric @ 2017-05-21 20:38 ` M. J. Everitt 2017-05-21 23:28 ` M. J. Everitt 1 sibling, 0 replies; 119+ messages in thread From: M. J. Everitt @ 2017-05-21 20:38 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: PGP/MIME version identification --] [-- Type: application/pgp-encrypted, Size: 11 bytes --] [-- Attachment #2: OpenPGP encrypted message --] [-- Type: application/octet-stream, Size: 2462 bytes --] -----BEGIN PGP MESSAGE----- hQIMA+SFlLe9WJ5DAQ//eAfIsZXFSI1pptkTgEkxUZIvCNLIxtLjCRel9xHSlg2v BMXoggVDhHPXf6kq6GSwTH7O59bacRAaEWQBuNYvg/XE/e8UvPVTQ9rXSWltqo88 rLEOZvtapWNzAoHchDVky5aUg7dJVNEodEd+doBqo2GQpwjAtzYr4al9CEMphtWJ HhKnfRbsG3Wx0TNRnX+rZST4slFik3He5cB+EJmHdub7yu/jSavdWjhQ3QHZhjRa 7OR09TcPeOpgvWG+u7+ta+H58dK3cVTES8Mmlp9UTfN2unoKTXXadHV6X6fy0uVR /d5UpZ9WgCXFrXbVHhDWRul8aQyDpJHeuKh+qFpVM4s/WYJb2Vs0eRMWnRotiP1Z ajnw0FGKspCSoAzpOF0qsBH+j0rCgHETHkChjaSWHGLhQUnSU0MTZZzAfyvkMoG5 WinMu/L3Ef9e2q7gBgn5inEKFCHCis/sSCMYQYoGtmvmcto7TZcOc2NaeYuYi4i6 /2DWNXtBz2KTU7udzaoeHOvoY+evZ5jfKd4pNNjeIc+Ctju3KMiaW32iLK91w4Ui hwe98+nzaxyCwi267mI2mz0WtwEsTLP4/yX7vwKGBgKuo4owwmirneLyfdm8YOxU 7nS+BSpiJEXOQPa1ocpShMBnyNNGNvD1y1CZHYzdv88Z9AfgkQJnspP+Rwt+dEGF AgwDNYPyd/z2VyQBD/9RLRIUEpj0gi6VLYOaEyIUjyODhoWGJTAiSgtxZ80WXd8y QLeb2/97YEIaPVo/s2pxJry6vri9be360fSMgjXZEraeK2GjqRpsEiJfp8PNft1g VGpwEaE8MifNz3hrNdz5Wm/fnc6V9EyeDqdmYPwi99Lgj9XYo9qFwUs0ivGU1sHU JyPQOxiKMdKR1B2gGFBw/NI1bGgRnd99I3Fg+Ba/YPJr6EQYpGzrm8/lMd4Onn98 JqsNQtb/mowrfFewd2dpGkFMS/vwLvE3CeZO6tFVjumozwbW1nrviZiRdyMAOlqS outFmmOINHyIoEGdzVes7r54LM/a6aAIsgaMnknLxMf9YqB/phqzrBrBUj3lJrwj /kdgPFvfMgjnCnG3gUKkCzo0bWpB3s+RVFmW4oCpZJH96sQy3J7jfiquYUl5N2L+ BsV/nGV4ZDmeNf70BVDiibY1hry7sZmBQfOV5FOtmIifTVZTyYWyBRMCDiE/P/jI nBqFH47H1XSU0wpaZDCIp8RmYEqSg8BkT6r5QC3ljAtwgNdrnyaprFIWGOYsYTUK s89kSIqURgIlldJa/1CJL8+QTOWgOmPQKmZ7AMJFkuEvbP0HbFjuk6dDZsKBKoag AgyrUitSKjJZWl85WH+0GqICoNtIUoQsrgChBwqLQDmk6yqnrLaYlQGvoKcjD9Lp AVamaQSiyFdqSw3gMEX8yvhEPKYSYJYUCkNfoya3ERWA8v3S83uhCQg5/S/0yhLt lklOjHNIpNpE52wxv6WGKb5tzYOfRX2TdyAKuiMCf+FCBHYB6gGpV0Azwh03KoDf /g+/n44muhSOIZQiuWeUBgAwEQLhe46afvjC9iHueG1fIdyoUWP6QI3CoWk1PR+E XSAydaZE3AMkeix4zted/Atd1bg7/3SYYeyLwiIh8ANvbVqRxubuX1CcaGigyHss 4Gi3IjPhI3wF+94Bgv2pZCn4/+kFae4/yYsALDxBAEY3okG05rnLhfEw8mu1jncD 0aiMhkg9O8djlIlRrk3O9j13U9DRHLwYGYWhceixu4Z0zUuGbHJQ8he5VNTLhzaY jfYm7x2HsOuvnOovYr4RWRi378YorY6DMvT71w4e67NQt1HXAPioAYfmygXFNkWk 1BDUBi/lf+aZRh/o37b5mY8mDVQJOdLy8fyyvXpkaQayPpFXxFavdrSAn5Nm4rJj zNFihvjY3QGwm8L1FWTGSp2qo7Y5eRptnE4FaPhnI2wjZfQAqM6yDXVCDDcLn+P0 1AaiesfHo+5QrU7yr5swhbai+CJRGbmrhNDsHYCXfGuTNUQ88Iit+r0xMmJiYDsj rzLNKR8hzVSNJye4fyOcq4ocsI9tdVtv7ofmv1HqYD7AC2T3sXw/WK68JBR/08l4 Ww1LZDSqeG/PNyppkSnaAKUBlgocYP+yFif9RRECLBG5smxbqF4BPDYB24rLCiqw cfrnXsAOKTh4vVG4tROb3iG9bi30h0IxSqj7/btiiVetNpY2gB4PIFWVuTXd3Cq/ 8vVJN1SgsKl7S9tQ972Lt+iTl84yU9zm9Fg3bw65/UdenPWru0/la66IZRv9YoH2 k7N4XFUNtUDMqfIaNZdIay3+FVQtXPHKUWQWwf/1vjX9LYJaor26LaG9kKoi =AOlz -----END PGP MESSAGE----- ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2017-05-21 19:32 ` Kent Fredric 2017-05-21 20:38 ` M. J. Everitt @ 2017-05-21 23:28 ` M. J. Everitt 1 sibling, 0 replies; 119+ messages in thread From: M. J. Everitt @ 2017-05-21 23:28 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 184 bytes --] On 21/05/17 20:32, Kent Fredric wrote: > But I'd also like a pony. > I'm hoping for a unicorn still ... [apologies, resending as hit the wrong button in the Compose button..] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2017-05-16 19:20 ` Michał Górny 2017-05-16 19:36 ` Fabian Groffen @ 2017-05-21 17:46 ` Raymond Jennings 2017-05-22 1:13 ` Luis Ressel 1 sibling, 1 reply; 119+ messages in thread From: Raymond Jennings @ 2017-05-21 17:46 UTC (permalink / raw To: gentoo-dev; +Cc: Mike Frysinger, qa [-- Attachment #1: Type: text/plain, Size: 1035 bytes --] On Tue, May 16, 2017 at 12:20 PM, Michał Górny <mgorny@gentoo.org> wrote: > Mike, > > I would really appreciate if you cared to follow procedures for eclass > changes. Most notably, if you at least bothered to either ping us *or* > sent the patch to the mailing list beforehand. > > This eclass is used by almost 6700 ebuilds. I am trying *hard* to commit > changes in large patchsets to reduce cache updates. Of course it is all > pointless if a random Mike Frysinger, developer on special rights, goes > ahead and commits whatever he wants to whatever eclasses he wants to > commit to, whatever time he pleases. > > Normally, I would revert it but I don't feel like causing third huge > cache update today. > Just out of curiosity, and for the curious: 1. How often do cache updates happen? 2. How long do they take? 3. Is there any downside to only having one such update running at a time and just skipping them if there's already an update pending? > > -- > Best regards, > Michał Górny > [-- Attachment #2: Type: text/html, Size: 1599 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2017-05-21 17:46 ` Raymond Jennings @ 2017-05-22 1:13 ` Luis Ressel 0 siblings, 0 replies; 119+ messages in thread From: Luis Ressel @ 2017-05-22 1:13 UTC (permalink / raw To: Raymond Jennings; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 607 bytes --] On Sun, 21 May 2017 10:46:25 -0700 Raymond Jennings <shentino@gmail.com> wrote: > Just out of curiosity, and for the curious: > > 1. How often do cache updates happen? > 2. How long do they take? > 3. Is there any downside to only having one such update running at a > time and just skipping them if there's already an update pending? I'm generating metadata locally. There are changes to some of the more important eclasses roughly every other week; and after such a change, the regen takes 10-25 minutes on my hardware. I don't understand your question (3). Regards, Luis Ressel [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1463773635.548f4ee19c6b0fe0d5e87e84a5a82c421229e0ce.johu@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1463773635.548f4ee19c6b0fe0d5e87e84a5a82c421229e0ce.johu@gentoo> @ 2016-05-20 19:55 ` Michał Górny 0 siblings, 0 replies; 119+ messages in thread From: Michał Górny @ 2016-05-20 19:55 UTC (permalink / raw To: Johannes Huber; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1460 bytes --] On Fri, 20 May 2016 19:47:55 +0000 (UTC) "Johannes Huber" <johu@gentoo.org> wrote: > commit: 548f4ee19c6b0fe0d5e87e84a5a82c421229e0ce > Author: Michael Palimaka <kensington <AT> gentoo <DOT> org> > AuthorDate: Fri May 20 19:46:11 2016 +0000 > Commit: Johannes Huber <johu <AT> gentoo <DOT> org> > CommitDate: Fri May 20 19:47:15 2016 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=548f4ee1 > > kde5.eclass: install all translations when LINGUAS is undefined > > This mirrors the behaviour of the gettext autotools macros. > > Gentoo-bug: 581382 > > Signed-off-by: Johannes Huber <johu <AT> gentoo.org> > > eclass/kde5.eclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/eclass/kde5.eclass b/eclass/kde5.eclass > index 377d2c5..eaffb9e 100644 > --- a/eclass/kde5.eclass > +++ b/eclass/kde5.eclass > @@ -397,7 +397,7 @@ kde5_src_prepare() { > > # enable only the requested translations > # when required > - if [[ -d po ]] ; then > + if [[ -d po && -v LINGUAS ]] ; then > pushd po > /dev/null || die > for lang in *; do > if [[ -d ${lang} ]] && ! has ${lang} ${LINGUAS} ; then This doesn't really make any difference since per EAPI 6 all USE_EXPAND variables (incl. LINGUAS) are always defined. The only reason it seems to work for you is due to a Portage bug. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1462655928.66afcab271f65b97330e610040ad3acc1b812a03.hd_brummy@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1462655928.66afcab271f65b97330e610040ad3acc1b812a03.hd_brummy@gentoo> @ 2016-05-07 21:25 ` Michał Górny 2016-05-07 21:48 ` Ryan Hill ` (3 more replies) 0 siblings, 4 replies; 119+ messages in thread From: Michał Górny @ 2016-05-07 21:25 UTC (permalink / raw To: Joerg Bornkessel; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1406 bytes --] On Sat, 7 May 2016 21:19:31 +0000 (UTC) "Joerg Bornkessel" <hd_brummy@gentoo.org> wrote: > commit: 66afcab271f65b97330e610040ad3acc1b812a03 > Author: Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org> > AuthorDate: Sat May 7 21:18:48 2016 +0000 > Commit: Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org> > CommitDate: Sat May 7 21:18:48 2016 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2 > > fixed einstall vs. emake install for eapi=6 > > eclass/vdr-plugin-2.eclass | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass > index ae09a34..65f1409 100644 > --- a/eclass/vdr-plugin-2.eclass > +++ b/eclass/vdr-plugin-2.eclass > @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() { > local SOFILE_STRING=$(grep SOFILE Makefile) > if [[ -n ${SOFILE_STRING} ]]; then > BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install }} > - einstall ${BUILD_PARAMS} \ > + if [[ ${EAPI} == 6 ]]; then > + emake install ${BUILD_PARAMS} \ > + else > + einstall ${BUILD_PARAMS} \ > + fi > ${BUILD_TARGETS} \ > TMPDIR="${T}" \ > DESTDIR="${D}" \ > Do you seriously expect this code to work? How about testing? Or reading diffs before committing? -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-07 21:25 ` Michał Górny @ 2016-05-07 21:48 ` Ryan Hill 2016-05-09 23:10 ` Doug Goldstein ` (2 subsequent siblings) 3 siblings, 0 replies; 119+ messages in thread From: Ryan Hill @ 2016-05-07 21:48 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1823 bytes --] On Sat, 7 May 2016 23:25:58 +0200 Michał Górny <mgorny@gentoo.org> wrote: > On Sat, 7 May 2016 21:19:31 +0000 (UTC) > "Joerg Bornkessel" <hd_brummy@gentoo.org> wrote: > > > commit: 66afcab271f65b97330e610040ad3acc1b812a03 > > Author: Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org> > > AuthorDate: Sat May 7 21:18:48 2016 +0000 > > Commit: Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org> > > CommitDate: Sat May 7 21:18:48 2016 +0000 > > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2 > > > > fixed einstall vs. emake install for eapi=6 > > > > eclass/vdr-plugin-2.eclass | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass > > index ae09a34..65f1409 100644 > > --- a/eclass/vdr-plugin-2.eclass > > +++ b/eclass/vdr-plugin-2.eclass > > @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() { > > local SOFILE_STRING=$(grep SOFILE Makefile) > > if [[ -n ${SOFILE_STRING} ]]; then > > BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install }} > > - einstall ${BUILD_PARAMS} \ > > + if [[ ${EAPI} == 6 ]]; then > > + emake install ${BUILD_PARAMS} \ > > + else > > + einstall ${BUILD_PARAMS} \ > > + fi > > ${BUILD_TARGETS} \ > > TMPDIR="${T}" \ > > DESTDIR="${D}" \ > > > > Do you seriously expect this code to work? How about testing? Or > reading diffs before committing? I reverted this commit since it broke sourcing any ebuild inheriting the eclass. I'm going to assume this commit was made by accident, since any dev that would commit code to an eclass without testing that it works, or even that it's _valid bash_, would not continue to have unsupervised commit rights for very long. -- [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 951 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-07 21:25 ` Michał Górny 2016-05-07 21:48 ` Ryan Hill @ 2016-05-09 23:10 ` Doug Goldstein 2016-05-13 8:52 ` Ian Delaney 2016-05-15 9:05 ` Jeroen Roovers 3 siblings, 0 replies; 119+ messages in thread From: Doug Goldstein @ 2016-05-09 23:10 UTC (permalink / raw To: gentoo-dev, Joerg Bornkessel [-- Attachment #1.1: Type: text/plain, Size: 1492 bytes --] On 5/7/16 4:25 PM, Michał Górny wrote: > On Sat, 7 May 2016 21:19:31 +0000 (UTC) > "Joerg Bornkessel" <hd_brummy@gentoo.org> wrote: > >> commit: 66afcab271f65b97330e610040ad3acc1b812a03 >> Author: Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org> >> AuthorDate: Sat May 7 21:18:48 2016 +0000 >> Commit: Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org> >> CommitDate: Sat May 7 21:18:48 2016 +0000 >> URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2 >> >> fixed einstall vs. emake install for eapi=6 >> >> eclass/vdr-plugin-2.eclass | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass >> index ae09a34..65f1409 100644 >> --- a/eclass/vdr-plugin-2.eclass >> +++ b/eclass/vdr-plugin-2.eclass >> @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() { >> local SOFILE_STRING=$(grep SOFILE Makefile) >> if [[ -n ${SOFILE_STRING} ]]; then >> BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install }} >> - einstall ${BUILD_PARAMS} \ >> + if [[ ${EAPI} == 6 ]]; then >> + emake install ${BUILD_PARAMS} \ >> + else >> + einstall ${BUILD_PARAMS} \ >> + fi >> ${BUILD_TARGETS} \ >> TMPDIR="${T}" \ >> DESTDIR="${D}" \ >> > > Do you seriously expect this code to work? How about testing? Or > reading diffs before committing? > Michal, How about trying a different tone? -- Doug Goldstein [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 959 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-07 21:25 ` Michał Górny 2016-05-07 21:48 ` Ryan Hill 2016-05-09 23:10 ` Doug Goldstein @ 2016-05-13 8:52 ` Ian Delaney 2016-05-14 9:55 ` Andreas K. Huettel 2016-05-14 11:55 ` Aaron Bauman 2016-05-15 9:05 ` Jeroen Roovers 3 siblings, 2 replies; 119+ messages in thread From: Ian Delaney @ 2016-05-13 8:52 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sat, 7 May 2016 23:25:58 +0200 Michał Górny <mgorny@gentoo.org> wrote: > On Sat, 7 May 2016 21:19:31 +0000 (UTC) > "Joerg Bornkessel" <hd_brummy@gentoo.org> wrote: > > > commit: 66afcab271f65b97330e610040ad3acc1b812a03 > > Author: Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org> > > AuthorDate: Sat May 7 21:18:48 2016 +0000 > > Commit: Joerg Bornkessel <hd_brummy <AT> gentoo <DOT> org> > > CommitDate: Sat May 7 21:18:48 2016 +0000 > > URL: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2 > > > > fixed einstall vs. emake install for eapi=6 > > > > eclass/vdr-plugin-2.eclass | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass > > index ae09a34..65f1409 100644 > > --- a/eclass/vdr-plugin-2.eclass > > +++ b/eclass/vdr-plugin-2.eclass > > @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() { > > local SOFILE_STRING=$(grep SOFILE Makefile) > > if [[ -n ${SOFILE_STRING} ]]; then > > BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install }} > > - einstall ${BUILD_PARAMS} \ > > + if [[ ${EAPI} == 6 ]]; then > > + emake install ${BUILD_PARAMS} \ > > + else > > + einstall ${BUILD_PARAMS} \ > > + fi > > ${BUILD_TARGETS} \ > > TMPDIR="${T}" \ > > DESTDIR="${D}" \ > > > > Do you seriously expect this code to work? How about testing? Or > reading diffs before committing? > Do you seriously expect us to sit and absorb this form of pious put down? From one who knows far better who is entitled to speak down to colleagues as is completely lacking a cerebral cortex? Those times are drawing to an end. Did anyone ever teach you to treat folk in such manner and expect them to respect it? I don't think so Not over my dead cvs perhaps - -- kind regards Ian Delaney -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJXNZW5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCRUI4RjAxNzRGRTVDMjI4RjcxNkRFNzIw QzQzN0NCNDcxRTlEMzNBAAoJEAxDfLRx6dM6mzcP/1BmrZw/EiuPlJh6MuufJ1/U Zlg26d99Vvvji0VVHcz9lrDhk6ubYB3WrcrG3E2M1pVwXDTuy+z5ez7RXvuUMSSY XiP4uWVWmlQoBlkAzAAvzKKVNsQvfOCif1x/b59Qjm9qAKQOwawTzCjOCHIrB08V EXFuuo5gpHfkq5vtU7jK22/6Zo56w+A7xfgSKl96byepA4F++3vDH4kX3XTBVmtE vlPn230CQqgP/YMZ/TBcQ4AE3r0fxPmGnAniZn/o5v2Zpzo1SZjrRlYJXDq3PnIa Rjs6fWEvfA7xu8wDt05Xz+8bzVXmS//1ga0VB1dmcNlVelUY7Pwi1kR+nUF174Vo /xLlTvK/EboliAMbviRwX9extWycWCB+iyBH/RkazaQQmSiW5tHlVPx8Wu7LiRay O8eFks7LgenetNBymMaiPBNZJMo/I+Fnebk43qx0XfUyuANLsg3JnsY4WG+Evcjc 3XqkTePuDyFLQEgQlU417JSFRkyZ0odMqpVShqOxgv4EA/HAiCpWCHkE1ZuiLi1V 7bKQodOclD3jTmy6eJgLpoEhqphXCaX9bl5QcFyu3+La8r3YXOqErCbOECoJy0Np lXwOCKZ9kvcv8iLygxKqP/0rxuAP0kzs5NSWd2zhHLRBihNvP+xkc2Pi4ztRT2LN Hju+wa0/WdLLTEPCAe78 =4iJI -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-13 8:52 ` Ian Delaney @ 2016-05-14 9:55 ` Andreas K. Huettel 2016-05-14 11:35 ` Ciaran McCreesh 2016-05-14 11:55 ` Aaron Bauman 1 sibling, 1 reply; 119+ messages in thread From: Andreas K. Huettel @ 2016-05-14 9:55 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney: > On Sat, 7 May 2016 23:25:58 +0200 > > > > Do you seriously expect this code to work? How about testing? Or > > reading diffs before committing? > > Do you seriously expect us to sit and absorb this form of pious > put down? From one who knows far better who is entitled to speak down > to colleagues as is completely lacking a cerebral cortex? Those times > are drawing to an end. Did anyone ever teach you to treat folk in such > manner and expect them to respect it? I don't think so > Not over my dead cvs perhaps Well, we still do need some commit quality, you know... - -- Andreas K. Huettel Gentoo Linux developer dilfridge@gentoo.org http://www.akhuettel.de/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJXNvYeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkXA4P/jDuTHnBkZfkzwjIbk6ZTi8J /sb/ypGT3h+tXUoYei2978drsF091WnDU6H+RCj3Lk4LKtPR6pMzL9OEXdihQqJh +OSZgh1T3pZJAjRWAVeXjgGmSlW9Pmxfnb1G9D9Zv+58cRohQhbZZG3baXih3QBY 2umIqYKgfbq+whtr49YYPVU6mVovQ8esWCAZWw5+vYqw2/9MDIUl4wWJVlDXgo7l Bmb2t5XudJ5lApfDGhOSaxi2lacPK2WggAlN2XmG5MkjPuQAauEQly8MhxlSUQxX Q8ZAyqzokPENXq0C+PwrF9TGBaFAQjMAnCLP7F4eo8jDqfsPhTxcthNQRhYXFpx6 /5aXEBb4DZwTOust9hdBUvUM5pUo7P9IyoBVGQdejo87YrLxy1MI0/J2E+GrRQfM HNRdAwRrhUpQrF6sCyD5mH7uVWdVwdhIY70Lau4d8HIP/J5TRN2FwP7F2zqjjQmz lUj20/meBvgHlGUgjsi2sb15HLwx2E2OkMrxhYcuE9JuBiaomBnz+OpSlzp2wGwR X1rXBVz/nvn2nVTH75QybLcjvTO9FfdfGFEGOrjQ/f68sTHpcat+Co9wJjYgD/LA EtUomNUkIFGcMJAyOBgdgZDiYREFXnlW1FlB94VS4SgcPpkcvxKBruM+DcJDgZ+h /F5kkAuRtmOsXBN2e1MT =5e68 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 9:55 ` Andreas K. Huettel @ 2016-05-14 11:35 ` Ciaran McCreesh 2016-05-14 11:55 ` M. J. Everitt 2016-05-14 15:04 ` Gordon Pettey 0 siblings, 2 replies; 119+ messages in thread From: Ciaran McCreesh @ 2016-05-14 11:35 UTC (permalink / raw To: gentoo-dev On Sat, 14 May 2016 11:55:42 +0200 > Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney: > > On Sat, 7 May 2016 23:25:58 +0200 > > > Do you seriously expect this code to work? How about testing? Or > > > reading diffs before committing? > > > > Do you seriously expect us to sit and absorb this form of pious > > put down? From one who knows far better who is entitled to speak > > down to colleagues as is completely lacking a cerebral cortex? > > Those times are drawing to an end. Did anyone ever teach you to > > treat folk in such manner and expect them to respect it? I don't > > think so Not over my dead cvs perhaps > > Well, we still do need some commit quality, you know... Why? Gentoo is about the community. Requiring a basic standard of commit quality a) reduces the number of community members who are able to contribute, 2) leads to fewer forums posts discussing how to fix problems, iii) hurts Gentoo's DistroWatch statistics by reducing the volume of commits, and fourthly, discriminates unfairly against competency-challenged developers by imposing subjective interpretations of the value of source code from a position of unearned authority. This is against the code of conduct, and is bad for the community! -- Ciaran McCreesh ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 11:35 ` Ciaran McCreesh @ 2016-05-14 11:55 ` M. J. Everitt 2016-05-14 15:04 ` Gordon Pettey 1 sibling, 0 replies; 119+ messages in thread From: M. J. Everitt @ 2016-05-14 11:55 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2759 bytes --] On 14/05/16 12:35, Ciaran McCreesh wrote: > On Sat, 14 May 2016 11:55:42 +0200 >> Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney: >>> On Sat, 7 May 2016 23:25:58 +0200 >>>> Do you seriously expect this code to work? How about testing? Or >>>> reading diffs before committing? >>> Do you seriously expect us to sit and absorb this form of pious >>> put down? From one who knows far better who is entitled to speak >>> down to colleagues as is completely lacking a cerebral cortex? >>> Those times are drawing to an end. Did anyone ever teach you to >>> treat folk in such manner and expect them to respect it? I don't >>> think so Not over my dead cvs perhaps >> Well, we still do need some commit quality, you know... > Why? Gentoo is about the community. Requiring a basic standard of commit > quality a) reduces the number of community members who are able to > contribute, 2) leads to fewer forums posts discussing how to fix > problems, iii) hurts Gentoo's DistroWatch statistics by reducing the > volume of commits, and fourthly, discriminates unfairly against > competency-challenged developers by imposing subjective interpretations > of the value of source code from a position of unearned authority. This > is against the code of conduct, and is bad for the community! > In defense of Gentoo at large .. the entry-level to contribute is really quite low .. and all the documentation for gentoo 'standards' is widely documented in both the Devmanual (under revision currently) and the Package Manager Spec. Not only this, but there are active projects within gentoo to welcome, nurture and develop devs and contributors alike so that there is a sustainable level of man-power available to keep up with the demands of users and pace of code development. Ok, it can be off-putting to those looking in from the outside, but really I think it benefits more than it costs. I agree broadly with the ethos of the QA team, gentoo tends to focus on quality over quantity where commits are concerned. It's better to retain a stable, reliable set of packages, with additional untested/unstable packages available via overlays, rather than a massive, unwieldy number of packages in a broadly unknown state. As it is, there is a deficit of active people maintaining the less-widely used packages, and also people able to add new packages to the tree, and this means that resources are inevitably spread more thinly. As always there will be a balance, but this thread did start out with some tit-for-tat between devs, totally unnecessary either in private or public. So, ditch that bike-shed, and get on with fixing bugs, closing issues, adding, updating and deprecating packages, folks :]. Thank you. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 11:35 ` Ciaran McCreesh 2016-05-14 11:55 ` M. J. Everitt @ 2016-05-14 15:04 ` Gordon Pettey 2016-05-14 16:53 ` Chí-Thanh Christopher Nguyễn 1 sibling, 1 reply; 119+ messages in thread From: Gordon Pettey @ 2016-05-14 15:04 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 796 bytes --] On Sat, May 14, 2016 at 6:35 AM, Ciaran McCreesh < ciaran.mccreesh@googlemail.com> wrote: > Why? Gentoo is about the community. Requiring a basic standard of commit > quality a) reduces the number of community members who are able to > contribute, 2) leads to fewer forums posts discussing how to fix > problems, iii) hurts Gentoo's DistroWatch statistics by reducing the > volume of commits, and fourthly, discriminates unfairly against > competency-challenged developers by imposing subjective interpretations > of the value of source code from a position of unearned authority. This > is against the code of conduct, and is bad for the community! > > So, it's perfectly okay to make direct commits of obviously broken code that has no chance of working, because community something mumble... [-- Attachment #2: Type: text/html, Size: 1188 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 15:04 ` Gordon Pettey @ 2016-05-14 16:53 ` Chí-Thanh Christopher Nguyễn 2016-05-14 16:59 ` M. J. Everitt 0 siblings, 1 reply; 119+ messages in thread From: Chí-Thanh Christopher Nguyễn @ 2016-05-14 16:53 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 379 bytes --] Gordon Pettey schrieb: > So, it's perfectly okay to make direct commits of obviously broken code that > has no chance of working, because community something mumble... You may have missed some sarcasm in the post which you replied to. Plus, I don't think anybody said or implied that committing broken things is ok. Best regards, Chí-Thanh Christopher Nguyễn [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 16:53 ` Chí-Thanh Christopher Nguyễn @ 2016-05-14 16:59 ` M. J. Everitt 2016-05-14 17:06 ` Rich Freeman 2016-05-14 20:06 ` Andreas K. Huettel 0 siblings, 2 replies; 119+ messages in thread From: M. J. Everitt @ 2016-05-14 16:59 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 742 bytes --] On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote: > Gordon Pettey schrieb: > >> So, it's perfectly okay to make direct commits of obviously broken >> code that >> has no chance of working, because community something mumble... > > You may have missed some sarcasm in the post which you replied to. > Plus, I don't think anybody said or implied that committing broken > things is ok. > > > Best regards, > Chí-Thanh Christopher Nguyễn > I think the time is coming, given the diversity of members of this list, to add <sarcasm></sarcasm> tags when we are not describing something literally. It becomes very difficult to follow the thread of conversation when people are (not) communicating their true thoughts!! [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 16:59 ` M. J. Everitt @ 2016-05-14 17:06 ` Rich Freeman 2016-05-14 17:07 ` landis blackwell 2016-05-14 17:08 ` M. J. Everitt 2016-05-14 20:06 ` Andreas K. Huettel 1 sibling, 2 replies; 119+ messages in thread From: Rich Freeman @ 2016-05-14 17:06 UTC (permalink / raw To: gentoo-dev On Sat, May 14, 2016 at 12:59 PM, M. J. Everitt <m.j.everitt@iee.org> wrote: > On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote: >> Gordon Pettey schrieb: >> >>> So, it's perfectly okay to make direct commits of obviously broken >>> code that >>> has no chance of working, because community something mumble... >> >> You may have missed some sarcasm in the post which you replied to. >> Plus, I don't think anybody said or implied that committing broken >> things is ok. >> >> >> Best regards, >> Chí-Thanh Christopher Nguyễn >> > I think the time is coming, given the diversity of members of this list, > to add <sarcasm></sarcasm> tags when we are not describing something > literally. It becomes very difficult to follow the thread of > conversation when people are (not) communicating their true thoughts!! > While this is certainly sensible, the irony here is that this whole discussion was started by somebody making a sarcastic remark when simply pointing out a mistake would have been just as functional. Nobody thinks it is ok to commit broken code. What it seems like we'll be debating until there is only one of us left is how unprofessional we should be when pointing that out. -- Rich ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 17:06 ` Rich Freeman @ 2016-05-14 17:07 ` landis blackwell 2016-05-14 17:52 ` Rich Freeman 2016-05-14 17:08 ` M. J. Everitt 1 sibling, 1 reply; 119+ messages in thread From: landis blackwell @ 2016-05-14 17:07 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1401 bytes --] No fun allowed On May 14, 2016 12:06 PM, "Rich Freeman" <rich0@gentoo.org> wrote: > On Sat, May 14, 2016 at 12:59 PM, M. J. Everitt <m.j.everitt@iee.org> > wrote: > > On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote: > >> Gordon Pettey schrieb: > >> > >>> So, it's perfectly okay to make direct commits of obviously broken > >>> code that > >>> has no chance of working, because community something mumble... > >> > >> You may have missed some sarcasm in the post which you replied to. > >> Plus, I don't think anybody said or implied that committing broken > >> things is ok. > >> > >> > >> Best regards, > >> Chí-Thanh Christopher Nguyễn > >> > > I think the time is coming, given the diversity of members of this list, > > to add <sarcasm></sarcasm> tags when we are not describing something > > literally. It becomes very difficult to follow the thread of > > conversation when people are (not) communicating their true thoughts!! > > > > While this is certainly sensible, the irony here is that this whole > discussion was started by somebody making a sarcastic remark when > simply pointing out a mistake would have been just as functional. > > Nobody thinks it is ok to commit broken code. What it seems like > we'll be debating until there is only one of us left is how > unprofessional we should be when pointing that out. > > -- > Rich > > [-- Attachment #2: Type: text/html, Size: 1886 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 17:07 ` landis blackwell @ 2016-05-14 17:52 ` Rich Freeman 2016-05-14 19:21 ` M. J. Everitt 0 siblings, 1 reply; 119+ messages in thread From: Rich Freeman @ 2016-05-14 17:52 UTC (permalink / raw To: gentoo-dev On Sat, May 14, 2016 at 1:07 PM, landis blackwell <blackwelllandis@gmail.com> wrote: > No fun allowed > Are you saying that you don't want people to have fun developing Gentoo? Or are you trying to say that it is impossible to have fun developing Gentoo without insulting strangers? I don't think anybody minds two friends teasing each other. -- Rich ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 17:52 ` Rich Freeman @ 2016-05-14 19:21 ` M. J. Everitt 2016-05-14 20:23 ` Rich Freeman 0 siblings, 1 reply; 119+ messages in thread From: M. J. Everitt @ 2016-05-14 19:21 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 575 bytes --] On 14/05/16 18:52, Rich Freeman wrote: > On Sat, May 14, 2016 at 1:07 PM, landis blackwell > <blackwelllandis@gmail.com> wrote: >> No fun allowed >> > Are you saying that you don't want people to have fun developing > Gentoo? Or are you trying to say that it is impossible to have fun > developing Gentoo without insulting strangers? I don't think anybody > minds two friends teasing each other. > I think my gut feeling would go "there's a time and a place..." .. and err on the g-dev ML probably not being it .. unless everyone else is in on the 'joke' .. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 19:21 ` M. J. Everitt @ 2016-05-14 20:23 ` Rich Freeman 2016-05-15 10:47 ` Daniel Campbell 0 siblings, 1 reply; 119+ messages in thread From: Rich Freeman @ 2016-05-14 20:23 UTC (permalink / raw To: gentoo-dev On Sat, May 14, 2016 at 3:21 PM, M. J. Everitt <m.j.everitt@iee.org> wrote: > On 14/05/16 18:52, Rich Freeman wrote: >> On Sat, May 14, 2016 at 1:07 PM, landis blackwell >> <blackwelllandis@gmail.com> wrote: >>> No fun allowed >>> >> Are you saying that you don't want people to have fun developing >> Gentoo? Or are you trying to say that it is impossible to have fun >> developing Gentoo without insulting strangers? I don't think anybody >> minds two friends teasing each other. >> > I think my gut feeling would go "there's a time and a place..." .. and > err on the g-dev ML probably not being it .. unless everyone else is in > on the 'joke' .. > Sure, and just to be clear I don't think we should be bothered by informality and joking around. If you have a good relationship with somebody and poking at each other is just how you relate, you can get away with it. We shouldn't have to walk on eggshells, but it just seems like we get a lot of flames in general going around and IMO at least it seems like it makes the distro a bit less fun. Of course we shouldn't lower our standards for quality, and I suspect that most of the people who do commit mistakes to the tree would probably agree, at least when they're sober. :) -- Rich ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 20:23 ` Rich Freeman @ 2016-05-15 10:47 ` Daniel Campbell 0 siblings, 0 replies; 119+ messages in thread From: Daniel Campbell @ 2016-05-15 10:47 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 2371 bytes --] On 05/14/2016 01:23 PM, Rich Freeman wrote: > On Sat, May 14, 2016 at 3:21 PM, M. J. Everitt <m.j.everitt@iee.org> wrote: >> On 14/05/16 18:52, Rich Freeman wrote: >>> On Sat, May 14, 2016 at 1:07 PM, landis blackwell >>> <blackwelllandis@gmail.com> wrote: >>>> No fun allowed >>>> >>> Are you saying that you don't want people to have fun developing >>> Gentoo? Or are you trying to say that it is impossible to have fun >>> developing Gentoo without insulting strangers? I don't think anybody >>> minds two friends teasing each other. >>> >> I think my gut feeling would go "there's a time and a place..." .. and >> err on the g-dev ML probably not being it .. unless everyone else is in >> on the 'joke' .. >> > > Sure, and just to be clear I don't think we should be bothered by > informality and joking around. If you have a good relationship with > somebody and poking at each other is just how you relate, you can get > away with it. We shouldn't have to walk on eggshells, but it just > seems like we get a lot of flames in general going around and IMO at > least it seems like it makes the distro a bit less fun. > > Of course we shouldn't lower our standards for quality, and I suspect > that most of the people who do commit mistakes to the tree would > probably agree, at least when they're sober. :) > I agree. Some of us have reputations for being hard to work with or being misunderstood, and it would go a long way for us to try to be honest and -- for lack of a better word -- nicer. I've not personally experienced much of that, but I can understand why someone wouldn't want to work with (on a volunteer basis, of course) someone calling them stupid or incompetent. Mistakes happen and I gladly fix anything I've screwed up. I could have taken some of the criticism personally due to the tone, however, if I hadn't been 'seasoned' by the Internet to expect the worst. That said, I like that those of us who are close can joke. We're all volunteers, so why not have fun *while* we build what we think is the ideal distro? I don't think quality and fun are mutually exclusive. "at least when they're sober" -- I had a hearty laugh at that one. :) -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 17:06 ` Rich Freeman 2016-05-14 17:07 ` landis blackwell @ 2016-05-14 17:08 ` M. J. Everitt 1 sibling, 0 replies; 119+ messages in thread From: M. J. Everitt @ 2016-05-14 17:08 UTC (permalink / raw To: gentoo-dev On 14/05/16 18:06, Rich Freeman wrote: > > While this is certainly sensible, the irony here is that this whole > discussion was started by somebody making a sarcastic remark when > simply pointing out a mistake would have been just as functional. > > Nobody thinks it is ok to commit broken code. What it seems like > we'll be debating until there is only one of us left is how > unprofessional we should be when pointing that out. > +1 .. is it time to add <irony> tags too?! :] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 16:59 ` M. J. Everitt 2016-05-14 17:06 ` Rich Freeman @ 2016-05-14 20:06 ` Andreas K. Huettel 1 sibling, 0 replies; 119+ messages in thread From: Andreas K. Huettel @ 2016-05-14 20:06 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Samstag, 14. Mai 2016, 18:59:02 schrieb M. J. Everitt: > > I think the time is coming, given the diversity of members of this list, > to add <sarcasm></sarcasm> tags when we are not describing something > literally. wouldnt a <ciaranm></ciaranm> tag be sufficient? - -- Andreas K. Huettel Gentoo Linux developer dilfridge@gentoo.org http://www.akhuettel.de/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJXN4VVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkXskQAJJ6LWQ1b0Ap27SAFGnTIqJb oYhGf8r3VoOxjVbqOKRVZnOZkudQ5KiURxUv+vAZbbomw4SMiV/gn1T/8V8xafbv KCL7UJOaW4AXgCZ+dFaV2jjTbVrFSMtvkeKwl3klpqPgylk9Q0Vudm1a058iBPRQ 9VPNX14Ooj3cKyimCYesznwH8cGv7cCUZA/MmjnqCQyKy+N5kxDyKyVdEECQ2bEY D/YDFoTtizixC8HS/OmOzRfCGRe3aPzHyzOMWL7FgCr9fnOE4METSa2kf9GQgViv 9g3RMfpQ4gudCQ/WcqEVDWUt8XlHxFvwdmleywP+Rh81MbUnkaLCA3dnk2Ev86su s2g5ltS2ozOlCkeryzenbZ1Ezk66kE6o+lBtC1MGWL5MDZVRZvIM1zCaYEqAwabC jDikqnGxWT3Lvyi7Jmus1p+vjty2LV00yA0JczED7tXSILUqW9ym2Trm/fAd1O+x NBMMnrrzWW28lyLFUZ+akRFvR35shE1KiISW7GVoorVKtmL8er6LkxYVkvjYi2Vn Ze+/mlxHNpJh1KjfQ3MC1MOqJQO3ZeOF0AFMPjxMvHFP+5J52PUdtTQeo68080kr UpFzlwE4nJj5CxMMYgqn7XVjgoaI/jZKqWdUN2h6cj2OwZIe58rIvKroWnUYaVOD 4IsP85PN+scg0Evuj4wa =jNhK -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-13 8:52 ` Ian Delaney 2016-05-14 9:55 ` Andreas K. Huettel @ 2016-05-14 11:55 ` Aaron Bauman 2016-05-14 13:54 ` Rich Freeman 1 sibling, 1 reply; 119+ messages in thread From: Aaron Bauman @ 2016-05-14 11:55 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1140 bytes --] On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote: > On Sat, 7 May 2016 23:25:58 +0200 > Michał Górny <mgorny@gentoo.org> wrote: > > > > Do you seriously expect this code to work? How about testing? Or > > reading diffs before committing? > > Absolutely nothing wrong was said here. Obviously the code was not tested and Michal pointed that out very plainly. > > > > > Do you seriously expect us to sit and absorb this form of pious > put down? From one who knows far better who is entitled to speak down > to colleagues as is completely lacking a cerebral cortex? Those times In one sentence you question him about putting someone down then in the next sentence you say he is lacking a cerebral cortex... hypocritical. > are drawing to an end. Did anyone ever teach you to treat folk in such > manner and expect them to respect it? I don't think so > Not over my dead cvs perhaps Not even really sure what that means? dead cvs? > > -- > kind regards > > Ian Delaney -- Cheers, Aaron Bauman Gentoo Linux Developer GnuPG FP: 1536 F4B3 72EB 9C54 11F5 5C43 246D 23A2 10FB 0F3E [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 951 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 11:55 ` Aaron Bauman @ 2016-05-14 13:54 ` Rich Freeman 2016-05-14 23:40 ` Aaron Bauman 0 siblings, 1 reply; 119+ messages in thread From: Rich Freeman @ 2016-05-14 13:54 UTC (permalink / raw To: gentoo-dev On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote: > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote: >> On Sat, 7 May 2016 23:25:58 +0200 >> Michał Górny <mgorny@gentoo.org> wrote: >> > >> > Do you seriously expect this code to work? How about testing? Or >> > reading diffs before committing? >> > > > Absolutely nothing wrong was said here. Obviously the code was not tested and > Michal pointed that out very plainly. > It is actually possible to communicate both plainly and politely at the same time. This does not require sacrificing any commitment to quality at all. Really the only downside is having more of an appearance of professionalism. -- Rich ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 13:54 ` Rich Freeman @ 2016-05-14 23:40 ` Aaron Bauman 2016-05-14 23:48 ` Ciaran McCreesh ` (3 more replies) 0 siblings, 4 replies; 119+ messages in thread From: Aaron Bauman @ 2016-05-14 23:40 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1260 bytes --] On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote: > On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote: > > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote: > >> On Sat, 7 May 2016 23:25:58 +0200 > >> > >> Michał Górny <mgorny@gentoo.org> wrote: > >> > Do you seriously expect this code to work? How about testing? Or > >> > reading diffs before committing? > > > > Absolutely nothing wrong was said here. Obviously the code was not tested > > and Michal pointed that out very plainly. > > It is actually possible to communicate both plainly and politely at > the same time. This does not require sacrificing any commitment to > quality at all. Really the only downside is having more of an > appearance of professionalism. Please enlighten me as to what was impolite here? The strong language of "seriously" or definitively stating that the individual did not perform the necessary QA actions before committing? Both of which are completely called for and appropriate. No vulgarity, insults, or demeaning words were used. How would you have responded professionally? -- Cheers, Aaron Bauman Gentoo Linux Developer GnuPG FP: 1536 F4B3 72EB 9C54 11F5 5C43 246D 23A2 10FB 0F3E [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 951 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 23:40 ` Aaron Bauman @ 2016-05-14 23:48 ` Ciaran McCreesh 2016-05-15 0:23 ` Aaron Bauman 2016-05-15 0:59 ` Rich Freeman ` (2 subsequent siblings) 3 siblings, 1 reply; 119+ messages in thread From: Ciaran McCreesh @ 2016-05-14 23:48 UTC (permalink / raw To: gentoo-dev On Sun, 15 May 2016 08:40:39 +0900 Aaron Bauman <bman@gentoo.org> wrote: > Please enlighten me as to what was impolite here? The strong > language of "seriously" or definitively stating that the individual > did not perform the necessary QA actions before committing? Both of > which are completely called for and appropriate. No vulgarity, > insults, or demeaning words were used. How would you have responded > professionally? It's important to remember that Gentoo is run by volunteers. Expecting a professional standard when it comes to the quality of commit criticism is unfair. -- Ciaran McCreesh ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 23:48 ` Ciaran McCreesh @ 2016-05-15 0:23 ` Aaron Bauman 2016-05-15 1:04 ` Rich Freeman 0 siblings, 1 reply; 119+ messages in thread From: Aaron Bauman @ 2016-05-15 0:23 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 984 bytes --] On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote: > On Sun, 15 May 2016 08:40:39 +0900 > > Aaron Bauman <bman@gentoo.org> wrote: > > Please enlighten me as to what was impolite here? The strong > > language of "seriously" or definitively stating that the individual > > did not perform the necessary QA actions before committing? Both of > > which are completely called for and appropriate. No vulgarity, > > insults, or demeaning words were used. How would you have responded > > professionally? > > It's important to remember that Gentoo is run by volunteers. Expecting > a professional standard when it comes to the quality of commit > criticism is unfair. Applying that same rationale, it would be unfair to say that an undescribed level of professionalism in communication is required as well. Nothing here violates the CoC. -- Cheers, Aaron Bauman Gentoo Linux Developer GnuPG FP: 1536 F4B3 72EB 9C54 11F5 5C43 246D 23A2 10FB 0F3E [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 951 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 0:23 ` Aaron Bauman @ 2016-05-15 1:04 ` Rich Freeman 2016-05-15 1:12 ` M. J. Everitt 2016-05-16 7:56 ` Ian Delaney 0 siblings, 2 replies; 119+ messages in thread From: Rich Freeman @ 2016-05-15 1:04 UTC (permalink / raw To: gentoo-dev On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman <bman@gentoo.org> wrote: > On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote: >> On Sun, 15 May 2016 08:40:39 +0900 >> >> Aaron Bauman <bman@gentoo.org> wrote: >> > Please enlighten me as to what was impolite here? The strong >> > language of "seriously" or definitively stating that the individual >> > did not perform the necessary QA actions before committing? Both of >> > which are completely called for and appropriate. No vulgarity, >> > insults, or demeaning words were used. How would you have responded >> > professionally? >> >> It's important to remember that Gentoo is run by volunteers. Expecting >> a professional standard when it comes to the quality of commit >> criticism is unfair. > > Applying that same rationale, it would be unfair to say that an undescribed > level of professionalism in communication is required as well. Nothing here > violates the CoC. > If you're only able to behave in a professional manner if the standards of professionalism are explicitly spelled out, I think you're missing the point. Ultimately it is an attitude. When you point out a mistake make it either about: 1. Helping the person who made the mistake to improve because you want to see them make better contributions (which they aren't going to do if you drive them off). 2. If you feel that somebody simply isn't going to cut it, then by all means report them so that their commit access can be revoked. Either of these has the potential to make Gentoo better. Simply posting flames isn't likely to change the behavior of people who need #2, and it is likely to discourage people who need #1. Either is against all of our interests in making the distro we benefit from better. -- Rich ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 1:04 ` Rich Freeman @ 2016-05-15 1:12 ` M. J. Everitt 2016-05-16 7:56 ` Ian Delaney 1 sibling, 0 replies; 119+ messages in thread From: M. J. Everitt @ 2016-05-15 1:12 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1878 bytes --] On 15/05/16 02:04, Rich Freeman wrote: > On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman <bman@gentoo.org> wrote: >> On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote: >>> On Sun, 15 May 2016 08:40:39 +0900 >>> >>> Aaron Bauman <bman@gentoo.org> wrote: >>>> Please enlighten me as to what was impolite here? The strong >>>> language of "seriously" or definitively stating that the individual >>>> did not perform the necessary QA actions before committing? Both of >>>> which are completely called for and appropriate. No vulgarity, >>>> insults, or demeaning words were used. How would you have responded >>>> professionally? >>> It's important to remember that Gentoo is run by volunteers. Expecting >>> a professional standard when it comes to the quality of commit >>> criticism is unfair. >> Applying that same rationale, it would be unfair to say that an undescribed >> level of professionalism in communication is required as well. Nothing here >> violates the CoC. >> > If you're only able to behave in a professional manner if the > standards of professionalism are explicitly spelled out, I think > you're missing the point. > > Ultimately it is an attitude. When you point out a mistake make it > either about: > 1. Helping the person who made the mistake to improve because you > want to see them make better contributions (which they aren't going to > do if you drive them off). > 2. If you feel that somebody simply isn't going to cut it, then by > all means report them so that their commit access can be revoked. > > Either of these has the potential to make Gentoo better. Simply > posting flames isn't likely to change the behavior of people who need > #2, and it is likely to discourage people who need #1. Either is > against all of our interests in making the distro we benefit from > better. > +1 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 1:04 ` Rich Freeman 2016-05-15 1:12 ` M. J. Everitt @ 2016-05-16 7:56 ` Ian Delaney 2016-05-16 8:20 ` Consus ` (2 more replies) 1 sibling, 3 replies; 119+ messages in thread From: Ian Delaney @ 2016-05-16 7:56 UTC (permalink / raw To: gentoo-dev On Sat, 14 May 2016 21:04:17 -0400 Rich Freeman <rich0@gentoo.org> wrote: I hope I won't regret this > On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman <bman@gentoo.org> wrote: > > On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote: > [...] > [...] > [...] > > > > Applying that same rationale, it would be unfair to say that an > > undescribed level of professionalism in communication is required > > as well. Nothing here violates the CoC. > > > No but it violates elements simply lot listed in the CoC. DO we need a better CoC? This undescribed level of professionalism is presumed assumed knowledge, or 'understood', however the evidence suggests it is FAR from 'understood'. Here is a point worth highlighting. While I find the language used to deliver the message an affront to my social senses, b-man does not and deems it apt to the situation. Herein therefore lies the dilemma. Being a communication instance, there are no clear rights or wrongs, but pure shades of grey. There are forms that most find fine and other most find a violation of social etiquette. The result is that this style of submissions and responses re issues over QA are tacitly accepted as valid and therefore endorsed. There is at least one other dev in high authority who has all but ticked the message as justified in the circumstances, while in other instances has placed a cross to the same dev's reply in a separate thread. This is predominantly why I refrain from sticking my neck out over this type of issue. Inevitably, by weight of numbers in the community, there will be someone who will vehemently reject and counter the point posed and attempt to shout it down as tripe. The point will be lost, or at least diluted to a meaningless mush. > If you're only able to behave in a professional manner if the > standards of professionalism are explicitly spelled out, I think > you're missing the point. > > Ultimately it is an attitude. When you point out a mistake make it > either about: > 1. Helping the person who made the mistake to improve because you > want to see them make better contributions (which they aren't going to > do if you drive them off). > 2. If you feel that somebody simply isn't going to cut it, then by > all means report them so that their commit access can be revoked. > rich0 here has hit the target a bullseye. The underlying attitude in the initial post displays a belief of justification and entitlement to 'shout down' the colleague and treat him with disdain over the blunder. This is NOT a bootcamp with paid drill sargeants. As long as this persists and is not intervened to polish and tidy up, g-devs will persist in making innocent, naive or incompetent blunders and run the gauntlet of being publicly scolded over errata. I can only express my view that this style of personal demeaning potentially results in embarrassment, public humiliation and drives community members away from participation. The ultimate negative influence. I would never entertain taking on eclass writing with the incumbent qa member delivering assessments under the title of 'code review' in the style he does. It is clear he has learned that he is not only entitled but expected to shout at folk for misdemeanours. hasufell also believed this, and scoffed when I suggested to him directly one never needs to shout, but rather speak in tempered moderate terms. Try it some time mgorny. The sky will not cave in. > Either of these has the potential to make Gentoo better. Simply > posting flames isn't likely to change the behavior of people who need > #2, and it is likely to discourage people who need #1. Either is > against all of our interests in making the distro we benefit from > better. > ditto -- kind regards Ian Delaney ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-16 7:56 ` Ian Delaney @ 2016-05-16 8:20 ` Consus 2016-05-16 8:30 ` Aaron Bauman 2016-05-16 9:05 ` Ciaran McCreesh 2 siblings, 0 replies; 119+ messages in thread From: Consus @ 2016-05-16 8:20 UTC (permalink / raw To: gentoo-dev On 15:56 Mon 16 May, Ian Delaney wrote: > On Sat, 14 May 2016 21:04:17 -0400 > Rich Freeman <rich0@gentoo.org> wrote: > > I hope I won't regret this > > > On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman <bman@gentoo.org> wrote: > > > On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote: > > [...] > > [...] > > [...] > > > > > > Applying that same rationale, it would be unfair to say that an > > > undescribed level of professionalism in communication is required > > > as well. Nothing here violates the CoC. > > > > > > > No but it violates elements simply lot listed in the CoC. DO we need a > better CoC? You need a better pair of balls; there is a chance that you will stop getting offended by random emails. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-16 7:56 ` Ian Delaney 2016-05-16 8:20 ` Consus @ 2016-05-16 8:30 ` Aaron Bauman 2016-05-16 9:05 ` Ciaran McCreesh 2 siblings, 0 replies; 119+ messages in thread From: Aaron Bauman @ 2016-05-16 8:30 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 5797 bytes --] On Monday, May 16, 2016 3:56:01 PM JST Ian Delaney wrote: > On Sat, 14 May 2016 21:04:17 -0400 > Rich Freeman <rich0@gentoo.org> wrote: > > I hope I won't regret this > > > On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman <bman@gentoo.org> wrote: > > > On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote: > > [...] > > [...] > > [...] > > > > > Applying that same rationale, it would be unfair to say that an > > > undescribed level of professionalism in communication is required > > > as well. Nothing here violates the CoC. > > No but it violates elements simply lot listed in the CoC. DO we need a > better CoC? > Apparently we do, because people will continue to find ways to complain about words and feelings. > This undescribed level of professionalism is presumed assumed > knowledge, or 'understood', however the evidence suggests it is FAR > from 'understood'. > No, everyone just has a different tolerance for words that hurt or don't hurt. Perceived intentions or the tone of a person behind a computer really doesn't matter to most. > Here is a point worth highlighting. While I find the language used to > deliver the message an affront to my social senses, b-man does not and > deems it apt to the situation. Herein therefore lies the dilemma. > Being a communication instance, there are no clear rights or wrongs, > but pure shades of grey. There are forms that most find fine and other Next on bookshelves we will have "50 shades of Gentoo"... who is ready?! > most find a violation of social etiquette. The result is that this > style of submissions and responses re issues over QA are tacitly > accepted as valid and therefore endorsed. There is at least one other > dev in high authority who has all but ticked the message as justified > in the circumstances, while in other instances has placed a cross to > the same dev's reply in a separate thread. > > This is predominantly why I refrain from sticking my neck out over > this type of issue. Inevitably, by weight of numbers in the community, > there will be someone who will vehemently reject and counter the point > posed and attempt to shout it down as tripe. The point will be lost, or > at least diluted to a meaningless mush. > I appluad your efforts to ensure that the social aspect of Gentoo is a pleasant one. The bottom line is that nothing wrong was said in this instance. > > If you're only able to behave in a professional manner if the > > standards of professionalism are explicitly spelled out, I think > > you're missing the point. > > Again, people come from various backgrounds and ideals so maybe it should be spelled out? That is completely unfeasible though hence the new book... > > Ultimately it is an attitude. When you point out a mistake make it > > either about: > > 1. Helping the person who made the mistake to improve because you > > want to see them make better contributions (which they aren't going to > > do if you drive them off). > > 2. If you feel that somebody simply isn't going to cut it, then by > > all means report them so that their commit access can be revoked. > I would prefer a simple "seriously...." email vice a report to QA and the revocation of my commit access. > rich0 here has hit the target a bullseye. The underlying attitude in > the initial post displays a belief of justification and entitlement to > 'shout down' the colleague and treat him with disdain over the blunder. > This is NOT a bootcamp with paid drill sargeants. > > As long as this persists and is not intervened to polish and tidy up, > g-devs will persist in making innocent, naive or incompetent blunders blunder: "a stupid or careless mistake." Are you redefining the word here or just calling the original violation stupid? Because that would seriously hurt some feelings. Semantics... what a condundrum. > and run the gauntlet of being publicly scolded over errata. I can only > express my view that this style of personal demeaning potentially > results in embarrassment, public humiliation and drives community > members away from participation. The ultimate negative influence. I > would never entertain taking on eclass writing with the incumbent qa > member delivering assessments under the title of 'code review' in the > style he does. > Thankfully someone is doing it. If you choose not to contribute, out of fear of an individual behind a computer, you should reevaluate why you are doing this. > It is clear he has learned that he is not only entitled but expected to > shout at folk for misdemeanours. hasufell also believed this, and > scoffed when I suggested to him directly one never needs to shout, but > rather speak in tempered moderate terms. > > Try it some time mgorny. The sky will not cave in. > Entitlement and privilege. The true essence of this whole problem. No one here wants to feel as though someone else is better or superior to them. I can only imagine though, that people believe individuals are sitting behind their computers just waiting for a bad piece of code to be committed so they can shout at someone. If either of those cases apply to anyone here you should find a new hobby. > > Either of these has the potential to make Gentoo better. Simply > > posting flames isn't likely to change the behavior of people who need > > #2, and it is likely to discourage people who need #1. Either is > > against all of our interests in making the distro we benefit from > > better. > > ditto I agree as well. However, the bottom line here is that nothing wrong was said, and a valid point was made to ensure the committer understood the severity of the mistake. Move on. -- Cheers, Aaron Bauman Gentoo Linux Developer GnuPG FP: 1536 F4B3 72EB 9C54 11F5 5C43 246D 23A2 10FB 0F3E [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 951 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-16 7:56 ` Ian Delaney 2016-05-16 8:20 ` Consus 2016-05-16 8:30 ` Aaron Bauman @ 2016-05-16 9:05 ` Ciaran McCreesh 2016-05-16 16:21 ` Andrew Savchenko 2 siblings, 1 reply; 119+ messages in thread From: Ciaran McCreesh @ 2016-05-16 9:05 UTC (permalink / raw To: gentoo-dev On Mon, 16 May 2016 15:56:01 +0800 Ian Delaney <idella4@gentoo.org> wrote: > As long as this persists and is not intervened to polish and tidy up, > g-devs will persist in making innocent, naive or incompetent blunders > and run the gauntlet of being publicly scolded over errata. I can only > express my view that this style of personal demeaning potentially > results in embarrassment, public humiliation and drives community > members away from participation. The ultimate negative influence. I > would never entertain taking on eclass writing with the incumbent qa > member delivering assessments under the title of 'code review' in the > style he does. If you're writing the kind of code that results in you being subjected to scathing criticism for breaking metadata generation for the entire tree, then discouraging you from contributing can only be good for the distribution... -- Ciaran McCreesh ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-16 9:05 ` Ciaran McCreesh @ 2016-05-16 16:21 ` Andrew Savchenko 2016-05-16 16:32 ` Andreas K. Huettel 0 siblings, 1 reply; 119+ messages in thread From: Andrew Savchenko @ 2016-05-16 16:21 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1331 bytes --] On Mon, 16 May 2016 10:05:33 +0100 Ciaran McCreesh wrote: > On Mon, 16 May 2016 15:56:01 +0800 > Ian Delaney <idella4@gentoo.org> wrote: > > As long as this persists and is not intervened to polish and tidy up, > > g-devs will persist in making innocent, naive or incompetent blunders > > and run the gauntlet of being publicly scolded over errata. I can only > > express my view that this style of personal demeaning potentially > > results in embarrassment, public humiliation and drives community > > members away from participation. The ultimate negative influence. I > > would never entertain taking on eclass writing with the incumbent qa > > member delivering assessments under the title of 'code review' in the > > style he does. > > If you're writing the kind of code that results in you being subjected > to scathing criticism for breaking metadata generation for the entire > tree, then discouraging you from contributing can only be good for the > distribution... Everyone can and will make mistakes, this is normal. Only those who do nothing make no mistakes. I see no reason why developer should be discouraged from contributing for a single blunder. Of course, if blunder rate is too high, comrel should take an action; but this is not the case here. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-16 16:21 ` Andrew Savchenko @ 2016-05-16 16:32 ` Andreas K. Huettel 0 siblings, 0 replies; 119+ messages in thread From: Andreas K. Huettel @ 2016-05-16 16:32 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Montag, 16. Mai 2016, 18:21:27 schrieb Andrew Savchenko: > > Everyone can and will make mistakes, this is normal. Only those who > do nothing make no mistakes. I see no reason why developer should > be discouraged from contributing for a single blunder. Of course, > if blunder rate is too high, comrel should take an action; but this > is not the case here. > Just for the record, this is where qa should step in, not comrel. - -- Andreas K. Huettel Gentoo Linux developer dilfridge@gentoo.org http://www.akhuettel.de/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJXOfYWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkx8UP/RyUttstbaWVUMiAQ1gZBYeh Ry93bojoZ+nV/H/vjVOGb6f2X2TtbyOx4c8krm/QekA/pMZCppn1oIpNRRaZdoPN TB165er/86NzXmoez9Hq5HFVFNbT56SFSyiTTT8uzbn2/phOsWy1FkwRD1Fjs4OA x9TZgrlFrnfwMlUHhtjbVQTuz0Cn+SYo1HSZ61hV5Y1YLm8MwSWZoS1mRDp65rD/ G5umBuhTHQplBY/ZBdvuR2R8/6/hQQfqI7E7wEj5MvUp98nReJjtYSP3c8WWQYhg 3OeGzyO+USIBGciSXu01ZUGQE4r7XnJ7uiq84wbp1PTVWXYCd8G6tmF7dMzgK8EO GfCfQuDNIAFgJSzIT0u0D1VltX47kdaWVzpet8qsjP+Ucr4cMvYyaDkrTP7cg0cY 8viaMpG3skVsiDRxRBy/E0mBbl0NxzSehZVxGV9x7f/lfsN8WIIlxID4RfisAWPf haXtclEKppbK9BdHXrBCYKFOBd0botAjYQhGylhwtnM/22N7v5SaHRezV7qaWYhw VsQiPht9NCZxkG9yVe/sz1J34YtQ8pB/qG2FJ+A7GQd8fjsay3M75UBQ2AJDLLhf CUOuyLCfZySMbdCPzPw4XevpMEsADnOMd6bal5uyUxQ2SvFDR0ub04mDf52p81Cd Qme479L9QJk3gKHzoGBw =uk3n -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 23:40 ` Aaron Bauman 2016-05-14 23:48 ` Ciaran McCreesh @ 2016-05-15 0:59 ` Rich Freeman 2016-05-15 1:12 ` M. J. Everitt 2016-05-15 9:53 ` Ryan Hill 2016-05-15 10:29 ` Michał Górny 3 siblings, 1 reply; 119+ messages in thread From: Rich Freeman @ 2016-05-15 0:59 UTC (permalink / raw To: gentoo-dev On Sat, May 14, 2016 at 7:40 PM, Aaron Bauman <bman@gentoo.org> wrote: > > Please enlighten me as to what was impolite here? The strong language of > "seriously" or definitively stating that the individual did not perform the > necessary QA actions before committing? He actually didn't "state" anything at all - he posted a set of rhetorical questions. And the use of "seriously" was inflammatory. In fact, if you're trying to avoid injecting passion into a discussion it is worth thinking carefully about just about any word ending in "ly" that you put into a sentence. Nine times out of ten the word isn't necessary and can cause more harm than good. > Both of which are completely called > for and appropriate. No vulgarity, insults, or demeaning words were used. I disagree. The tone was uncivil and demeaning. > How would you have responded professionally? > How about this: You inserted this code snippet into the middle of a command line, so it is certain to break in either case. This should have been detected during testing; please be sure to test changes to ebuilds/eclasses before committing them. Additionally eclass changes should be submitted to the lists for review in any case prior to being committed. Or by all means refer the issue to QA/Comrel if you want to escalate it. I'm in no way suggesting that we should accept bad commits. IMO when we see bad commits we should: 1. Just point them out politely if it is a one-off. ANYBODY can make a mistake. 2. If they're a trend or show signs of bad practices like not testing changes then escalate to QA/Comrel. 3. Let QA/Comrel do their job and block commit access or refer the dev for more mentoring/etc as appropriate. Then we actually fix the problem instead of just yelling at each other. -- Rich ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 0:59 ` Rich Freeman @ 2016-05-15 1:12 ` M. J. Everitt 0 siblings, 0 replies; 119+ messages in thread From: M. J. Everitt @ 2016-05-15 1:12 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1928 bytes --] On 15/05/16 01:59, Rich Freeman wrote: > On Sat, May 14, 2016 at 7:40 PM, Aaron Bauman <bman@gentoo.org> wrote: >> Please enlighten me as to what was impolite here? The strong language of >> "seriously" or definitively stating that the individual did not perform the >> necessary QA actions before committing? > He actually didn't "state" anything at all - he posted a set of > rhetorical questions. And the use of "seriously" was inflammatory. > In fact, if you're trying to avoid injecting passion into a discussion > it is worth thinking carefully about just about any word ending in > "ly" that you put into a sentence. Nine times out of ten the word > isn't necessary and can cause more harm than good. > >> Both of which are completely called >> for and appropriate. No vulgarity, insults, or demeaning words were used. > I disagree. The tone was uncivil and demeaning. > >> How would you have responded professionally? >> > How about this: > > You inserted this code snippet into the middle of a command line, so > it is certain to break in either case. This should have been detected > during testing; please be sure to test changes to ebuilds/eclasses > before committing them. Additionally eclass changes should be > submitted to the lists for review in any case prior to being > committed. > > Or by all means refer the issue to QA/Comrel if you want to escalate it. > > I'm in no way suggesting that we should accept bad commits. IMO when > we see bad commits we should: > > 1. Just point them out politely if it is a one-off. ANYBODY can make > a mistake. > 2. If they're a trend or show signs of bad practices like not testing > changes then escalate to QA/Comrel. > 3. Let QA/Comrel do their job and block commit access or refer the > dev for more mentoring/etc as appropriate. Then we actually fix the > problem instead of just yelling at each other. > +1 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 23:40 ` Aaron Bauman 2016-05-14 23:48 ` Ciaran McCreesh 2016-05-15 0:59 ` Rich Freeman @ 2016-05-15 9:53 ` Ryan Hill 2016-05-15 11:04 ` Daniel Campbell 2016-05-15 18:43 ` Andreas K. Huettel 2016-05-15 10:29 ` Michał Górny 3 siblings, 2 replies; 119+ messages in thread From: Ryan Hill @ 2016-05-15 9:53 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1539 bytes --] On Sun, 15 May 2016 08:40:39 +0900 Aaron Bauman <bman@gentoo.org> wrote: > On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote: > > On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote: > > > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote: > > >> On Sat, 7 May 2016 23:25:58 +0200 > > >> > > >> Michał Górny <mgorny@gentoo.org> wrote: > > >> > Do you seriously expect this code to work? How about testing? Or > > >> > reading diffs before committing? > > > > > > Absolutely nothing wrong was said here. Obviously the code was not tested > > > and Michal pointed that out very plainly. > > > > It is actually possible to communicate both plainly and politely at > > the same time. This does not require sacrificing any commitment to > > quality at all. Really the only downside is having more of an > > appearance of professionalism. > > Please enlighten me as to what was impolite here? The strong language of > "seriously" or definitively stating that the individual did not perform the > necessary QA actions before committing? Both of which are completely called > for and appropriate. No vulgarity, insults, or demeaning words were used. > How would you have responded professionally? I thought his response was pretty tame actually. If you break the tree because you couldn't be bothered to do the barest minimum of testing you absolutely deserve to be called out on it. But if you guys just want to hug it out that's cool too. -- [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 951 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 9:53 ` Ryan Hill @ 2016-05-15 11:04 ` Daniel Campbell 2016-05-15 22:55 ` Duncan 2016-05-15 18:43 ` Andreas K. Huettel 1 sibling, 1 reply; 119+ messages in thread From: Daniel Campbell @ 2016-05-15 11:04 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 2409 bytes --] On 05/15/2016 02:53 AM, Ryan Hill wrote: > On Sun, 15 May 2016 08:40:39 +0900 > Aaron Bauman <bman@gentoo.org> wrote: > >> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote: >>> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote: >>>> On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote: >>>>> On Sat, 7 May 2016 23:25:58 +0200 >>>>> >>>>> Michał Górny <mgorny@gentoo.org> wrote: >>>>>> Do you seriously expect this code to work? How about testing? Or >>>>>> reading diffs before committing? >>>> >>>> Absolutely nothing wrong was said here. Obviously the code was not tested >>>> and Michal pointed that out very plainly. >>> >>> It is actually possible to communicate both plainly and politely at >>> the same time. This does not require sacrificing any commitment to >>> quality at all. Really the only downside is having more of an >>> appearance of professionalism. >> >> Please enlighten me as to what was impolite here? The strong language of >> "seriously" or definitively stating that the individual did not perform the >> necessary QA actions before committing? Both of which are completely called >> for and appropriate. No vulgarity, insults, or demeaning words were used. >> How would you have responded professionally? > > I thought his response was pretty tame actually. If you break the tree > because you couldn't be bothered to do the barest minimum of testing you > absolutely deserve to be called out on it. > > But if you guys just want to hug it out that's cool too. > I think that depends on history. If the dev in question hasn't done that before, then it's entirely possible they *thought* they tested, or tested it *before* making some other edit and absent-mindedly committed. That's a screw-up, and devs should be notified. Ideally, they should be told *what* they screwed up and *how* to ensure it doesn't happen again. Admonishing them as if they were a child is not going to engender motivation to continue participation. We're all devs because we want to make Gentoo better (I hope, anyway), and part of that means we'll have to help each other out sometimes. There's more to it than coddling vs tearing someone down. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 11:04 ` Daniel Campbell @ 2016-05-15 22:55 ` Duncan 2016-05-15 23:07 ` Daniel Campbell 2016-05-16 0:12 ` M. J. Everitt 0 siblings, 2 replies; 119+ messages in thread From: Duncan @ 2016-05-15 22:55 UTC (permalink / raw To: gentoo-dev Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted: > If the dev in question hasn't done that before, then it's entirely > possible they *thought* they tested, or tested it *before* making some > other edit and absent-mindedly committed. Again, legacy CVS thought pattern. In git, commit != push, and it's the push that's critical. Commit all you want without testing. Just test (and fix if necessary) before you push those commits up to the gentoo master repo. =:^) (Of course, rebasing to fold the broken commit and its fix into one before pushing doesn't hurt, either.) -- 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 ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 22:55 ` Duncan @ 2016-05-15 23:07 ` Daniel Campbell 2016-05-16 0:12 ` M. J. Everitt 1 sibling, 0 replies; 119+ messages in thread From: Daniel Campbell @ 2016-05-15 23:07 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 1054 bytes --] On 05/15/2016 03:55 PM, Duncan wrote: > Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted: > >> If the dev in question hasn't done that before, then it's entirely >> possible they *thought* they tested, or tested it *before* making some >> other edit and absent-mindedly committed. > > Again, legacy CVS thought pattern. In git, commit != push, and it's the > push that's critical. > > Commit all you want without testing. Just test (and fix if necessary) > before you push those commits up to the gentoo master repo. =:^) > > (Of course, rebasing to fold the broken commit and its fix into one > before pushing doesn't hurt, either.) > Sorry. I've actually been using git for years, but since I got started with Gentoo on CVS and I try to be careful with my commits to the gentoo repo, I conflated them. You're right, the push is what matters the most. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 22:55 ` Duncan 2016-05-15 23:07 ` Daniel Campbell @ 2016-05-16 0:12 ` M. J. Everitt 1 sibling, 0 replies; 119+ messages in thread From: M. J. Everitt @ 2016-05-16 0:12 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 836 bytes --] On 15/05/16 23:55, Duncan wrote: > Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted: > >> If the dev in question hasn't done that before, then it's entirely >> possible they *thought* they tested, or tested it *before* making some >> other edit and absent-mindedly committed. > Again, legacy CVS thought pattern. In git, commit != push, and it's the > push that's critical. > > Commit all you want without testing. Just test (and fix if necessary) > before you push those commits up to the gentoo master repo. =:^) > > (Of course, rebasing to fold the broken commit and its fix into one > before pushing doesn't hurt, either.) > Surely it should be possible to fire some QA scripts on pre-commit on the central gentoo repos (ie. at the push target end)?! Or am I being a bit optimistic .. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 9:53 ` Ryan Hill 2016-05-15 11:04 ` Daniel Campbell @ 2016-05-15 18:43 ` Andreas K. Huettel 1 sibling, 0 replies; 119+ messages in thread From: Andreas K. Huettel @ 2016-05-15 18:43 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Sonntag, 15. Mai 2016, 11:53:27 schrieb Ryan Hill: > > I thought his response was pretty tame actually. If you break the tree > because you couldn't be bothered to do the barest minimum of testing you > absolutely deserve to be called out on it. > +1 - -- Andreas K. Huettel Gentoo Linux developer dilfridge@gentoo.org http://www.akhuettel.de/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJXOMNKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnk+j8P/0EpX59Qy0s6K9kuSvZTkzki w/P3jDKqfcFSkyZQFBHRXGKkyME/9uvCDxjvUzNlSGaw5Ukvl1CWzFN5Z1sxzLVU wcu5nMaumt26egFmTliGwIWLXT7dbaqIyprCUPCF2HMbvsSBWKJ0Us+36Saz0NA3 G69ZBuO7Ig8t+yS5pcXkUUy6yqbDL2zaStIDxM5V5N0joVwetKt6CIXWiBMprRGP L64VPi3FkVuuf4a04HMLzBl27kNRPiCvNMPZlf8Sp5b0ve4C6MapUvJ5BHSX64Hy CtXEMPHrLtfFPE7fAW7EQlXKSRbpgkw3SIRI+TgpeMbwLaYkPkqf3NH5J3z1Gph+ CIhceVFq5gXexsbo4O3+deRXXSYraEZhZfYJKrXpiwEVVBTEpdtPrugOQoPMRo4H pAlG8dQA456IqXGS4nur4sRljQg8rhfPnx5/vD6AnD+9gCM0qF9V/GinIBDvXOZd QPzcaJn14MBS7xvN/jcy3Lf/ZJvjUMqb4MGKvCxvhNUFDIXHWRvqv5br3eMw6JSB 78wmN4kTcfFeQ9ywCChSKZDRZTziLVWifAORSJduGuyP/NthzPFMT3OrYS1Mze8v JIHB+9HsmCG5RwXuP/DMAb0t0dg6Lbg8qKBtRvsO72/bsVfU50AtDDFXGowaK386 A24gQh9cIvtqRo8lU+nY =vysH -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-14 23:40 ` Aaron Bauman ` (2 preceding siblings ...) 2016-05-15 9:53 ` Ryan Hill @ 2016-05-15 10:29 ` Michał Górny 2016-05-15 11:16 ` Daniel Campbell 3 siblings, 1 reply; 119+ messages in thread From: Michał Górny @ 2016-05-15 10:29 UTC (permalink / raw To: Aaron Bauman; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2788 bytes --] On Sun, 15 May 2016 08:40:39 +0900 Aaron Bauman <bman@gentoo.org> wrote: > On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote: > > On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote: > > > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote: > > >> On Sat, 7 May 2016 23:25:58 +0200 > > >> > > >> Michał Górny <mgorny@gentoo.org> wrote: > > >> > Do you seriously expect this code to work? How about testing? Or > > >> > reading diffs before committing? > > > > > > Absolutely nothing wrong was said here. Obviously the code was not tested > > > and Michal pointed that out very plainly. > > > > It is actually possible to communicate both plainly and politely at > > the same time. This does not require sacrificing any commitment to > > quality at all. Really the only downside is having more of an > > appearance of professionalism. > > Please enlighten me as to what was impolite here? The strong language of > "seriously" or definitively stating that the individual did not perform the > necessary QA actions before committing? Both of which are completely called > for and appropriate. No vulgarity, insults, or demeaning words were used. > How would you have responded professionally? Since the anti-productivity of this thread is getting impressively high even for Gentoo standards, I'd like to point out a few things. It was impolite. It was supposed to be. Not offensive but impolite. It ain't cool to get responses like this but it ain't cool to break stuff like this either. For those who don't have a broader view, it wasn't a single commit but a followup to a commit adding EAPI=6 support to the eclass -- clearly untested. I didn't bother complaining about the first one since issues would clearly pop up if someone actually tried to use the eclass in EAPI=6. However, the second commit actually introduced a syntax error that broke all the ebuilds, including stable and caused metadata generation failure. This is real bad. Of course, it could have been worse. It looks like no ebuilds with EAPI=6 'support' were committed following the eclass. Which is a good sign that some testing eventually occurred. However, is it that much of an effort to test eclass changes using ebuilds *before* committing it? It wasn't that hard even in times of CVS (esp. that we're talking about separate directories), and it is even easier in times of git. I don't really see the benefit of whole of this discussion. He committed a bad thing, I shouted at him, end of story. If you want to take it to comrel, just do it. However, discussing whether it was right or wrong is really unproductive here. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 10:29 ` Michał Górny @ 2016-05-15 11:16 ` Daniel Campbell 2016-05-15 22:46 ` Duncan 0 siblings, 1 reply; 119+ messages in thread From: Daniel Campbell @ 2016-05-15 11:16 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 4549 bytes --] On 05/15/2016 03:29 AM, Michał Górny wrote: > On Sun, 15 May 2016 08:40:39 +0900 > Aaron Bauman <bman@gentoo.org> wrote: > >> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote: >>> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman <bman@gentoo.org> wrote: >>>> On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote: >>>>> On Sat, 7 May 2016 23:25:58 +0200 >>>>> >>>>> Michał Górny <mgorny@gentoo.org> wrote: >>>>>> Do you seriously expect this code to work? How about testing? Or >>>>>> reading diffs before committing? >>>> >>>> Absolutely nothing wrong was said here. Obviously the code was not tested >>>> and Michal pointed that out very plainly. >>> >>> It is actually possible to communicate both plainly and politely at >>> the same time. This does not require sacrificing any commitment to >>> quality at all. Really the only downside is having more of an >>> appearance of professionalism. >> >> Please enlighten me as to what was impolite here? The strong language of >> "seriously" or definitively stating that the individual did not perform the >> necessary QA actions before committing? Both of which are completely called >> for and appropriate. No vulgarity, insults, or demeaning words were used. >> How would you have responded professionally? > > Since the anti-productivity of this thread is getting impressively high > even for Gentoo standards, I'd like to point out a few things. > > It was impolite. It was supposed to be. Not offensive but impolite. It > ain't cool to get responses like this but it ain't cool to break stuff > like this either. > > For those who don't have a broader view, it wasn't a single commit but > a followup to a commit adding EAPI=6 support to the eclass -- clearly > untested. I didn't bother complaining about the first one since issues > would clearly pop up if someone actually tried to use the eclass > in EAPI=6. However, the second commit actually introduced a syntax > error that broke all the ebuilds, including stable and caused metadata > generation failure. This is real bad. > > Of course, it could have been worse. It looks like no ebuilds with > EAPI=6 'support' were committed following the eclass. Which is a good > sign that some testing eventually occurred. However, is it that much of > an effort to test eclass changes using ebuilds *before* committing it? > It wasn't that hard even in times of CVS (esp. that we're talking about > separate directories), and it is even easier in times of git. > > I don't really see the benefit of whole of this discussion. He > committed a bad thing, I shouted at him, end of story. If you want to > take it to comrel, just do it. However, discussing whether it was right > or wrong is really unproductive here. > I felt it was a bit strong, but you make a good case. There certainly is a balance. One can't coddle someone who's breaking the tree, especially when we expect people to test before committing. Since it was an eclass, wasn't that supposed to be discussed on here first, too? Still, we're going to make mistakes and dressing someone down won't fix it. When I was adding multilib support to media-sound/apulse I recall you strongly telling me that I screwed up and it shouldn't have been done the way I originally committed. There wasn't a nudge in the right direction, though. I imagine it was clear that I hadn't done multilib scripts before. If I had been more sensitive or less willing to fix it, what would have happened? You or someone else may have reverted it and/or reported to QA and started a ruckus. I mean, I don't hold a grudge or anything. I'm glad you told me it wasn't right, because if I'm contributing to Gentoo I want it to be done well. I learned something from it. But a dev being told that they're screwing up without also being specific (or at least a hint) about a way to fix it or *why* it's wrong doesn't help them fix their screw up and ensure it doesn't happen again. That sort of criticism, which may be warranted in terms of "they screwed the tree up due to something stupid!", isn't productive if the dev doesn't know how to fix it. This particular screw-up is different since it was simpler, but less trivial screw ups do happen and without _constructive_ criticism, devs (and Gentoo, by extension) won't get better. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 11:16 ` Daniel Campbell @ 2016-05-15 22:46 ` Duncan 2016-05-15 23:19 ` Rich Freeman 0 siblings, 1 reply; 119+ messages in thread From: Duncan @ 2016-05-15 22:46 UTC (permalink / raw To: gentoo-dev Daniel Campbell posted on Sun, 15 May 2016 04:16:30 -0700 as excerpted: > On 05/15/2016 03:29 AM, Michał Górny wrote: >> However, is it that much of >> an effort to test eclass changes using ebuilds *before* committing it? >> It wasn't that hard even in times of CVS (esp. that we're talking about >> separate directories), and it is even easier in times of git. >> > One can't coddle someone who's breaking the tree, especially > when we expect people to test before committing. Orthogonal to the general discussion, but could be critical for some... Both the above comments reflect legacy CVS thought patterns in regard to commits. In git, commit != push , and here it's the push, not the commit, that's critical and that testing needs done before. Committing without testing, as long as you don't push, is fine, even meritorious. It's the push that uploads those commits to the gentoo reference repo, however, and testing should *definitely* be done before pushing, with more commits /before/ the push to fix what the tests found to be broken, should they be necessary. (Tho in keeping with the principle of ultimately atomic commits that don't break bisections, if a commit is found to be broken and is then fixed by another commit, a rebase to combine the two into one should be considered, thus avoiding breakage of bisections ending up with a commit between the break and its fix. Not that bisection is particularly practical in the gentoo repo context anyway, but that's a separate discussion, and good habits here will carry over to repos where bisection is actually practical and critically important.) -- 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 ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 22:46 ` Duncan @ 2016-05-15 23:19 ` Rich Freeman 0 siblings, 0 replies; 119+ messages in thread From: Rich Freeman @ 2016-05-15 23:19 UTC (permalink / raw To: gentoo-dev On Sun, May 15, 2016 at 6:46 PM, Duncan <1i5t5.duncan@cox.net> wrote: > > Committing without testing, as long as you don't push, is fine, even > meritorious. It's the push that uploads those commits to the gentoo > reference repo, however, and testing should *definitely* be done before > pushing, with more commits /before/ the push to fix what the tests found > to be broken, should they be necessary. > Of course. In fact, this is often the type of workflow you'd tend to employ in a CI setup. I believe that pull requests submitted on github get automatically tinderboxed, though I have no idea whether that provides any benefits to something like an eclass (if the CI script just tests the ebuilds being modified it obviously would not). Maybe in a perfect world we'd actually have a CI testing package category with dummy packages that do nothing but run tests to cover this sort of thing. Even so, I would imagine that in most organizations CI is intended more as a sanity check than a substitute for testing your own work. Certainly where I work the expectation is that somebody would have at least compiled and run something before putting it into some kind of QA workflow, even with CI. -- Rich ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-07 21:25 ` Michał Górny ` (2 preceding siblings ...) 2016-05-13 8:52 ` Ian Delaney @ 2016-05-15 9:05 ` Jeroen Roovers 2016-05-15 9:15 ` Brian Dolbec 3 siblings, 1 reply; 119+ messages in thread From: Jeroen Roovers @ 2016-05-15 9:05 UTC (permalink / raw To: gentoo-dev On Sat, 7 May 2016 23:25:58 +0200 Michał Górny <mgorny@gentoo.org> wrote: > Do you seriously expect this code to work? How about testing? Or > reading diffs before committing? Somebody could have a go at implementing this: https://bugs.gentoo.org/show_bug.cgi?id=390651 It's been brewing for half a decade. Maybe it's time. :) Regards, jer ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 9:05 ` Jeroen Roovers @ 2016-05-15 9:15 ` Brian Dolbec 2016-05-15 11:18 ` Daniel Campbell 0 siblings, 1 reply; 119+ messages in thread From: Brian Dolbec @ 2016-05-15 9:15 UTC (permalink / raw To: gentoo-dev On Sun, 15 May 2016 11:05:21 +0200 Jeroen Roovers <jer@gentoo.org> wrote: > On Sat, 7 May 2016 23:25:58 +0200 > Michał Górny <mgorny@gentoo.org> wrote: > > > Do you seriously expect this code to work? How about testing? Or > > reading diffs before committing? > > > Somebody could have a go at implementing this: > > https://bugs.gentoo.org/show_bug.cgi?id=390651 > > It's been brewing for half a decade. Maybe it's time. :) > > > Regards, > jer > With the new repoman code structure, yes, it would be a lot easier to implement. Also with the gen-b0rk test repo, that will be a good testing ground for eclass changes too. It just needs more devs to make test ebuilds to get it fully populated ;) -- Brian Dolbec <dolsen> ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 9:15 ` Brian Dolbec @ 2016-05-15 11:18 ` Daniel Campbell 2016-05-15 14:27 ` Brian Dolbec 0 siblings, 1 reply; 119+ messages in thread From: Daniel Campbell @ 2016-05-15 11:18 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 1115 bytes --] On 05/15/2016 02:15 AM, Brian Dolbec wrote: > On Sun, 15 May 2016 11:05:21 +0200 > Jeroen Roovers <jer@gentoo.org> wrote: > >> On Sat, 7 May 2016 23:25:58 +0200 >> Michał Górny <mgorny@gentoo.org> wrote: >> >>> Do you seriously expect this code to work? How about testing? Or >>> reading diffs before committing? >> >> >> Somebody could have a go at implementing this: >> >> https://bugs.gentoo.org/show_bug.cgi?id=390651 >> >> It's been brewing for half a decade. Maybe it's time. :) >> >> >> Regards, >> jer >> > > With the new repoman code structure, yes, it would be a lot easier to > implement. > > Also with the gen-b0rk test repo, that will be a good testing ground > for eclass changes too. It just needs more devs to make test ebuilds > to get it fully populated ;) > What sort of test ebuilds are you looking for? There are a few packages I'd like to see get into Gentoo but I don't want to break anything. :P -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-05-15 11:18 ` Daniel Campbell @ 2016-05-15 14:27 ` Brian Dolbec 0 siblings, 0 replies; 119+ messages in thread From: Brian Dolbec @ 2016-05-15 14:27 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1556 bytes --] On Sun, 15 May 2016 04:18:39 -0700 Daniel Campbell <zlg@gentoo.org> wrote: > On 05/15/2016 02:15 AM, Brian Dolbec wrote: > > On Sun, 15 May 2016 11:05:21 +0200 > > Jeroen Roovers <jer@gentoo.org> wrote: > > > >> On Sat, 7 May 2016 23:25:58 +0200 > >> Michał Górny <mgorny@gentoo.org> wrote: > >> > >>> Do you seriously expect this code to work? How about testing? Or > >>> reading diffs before committing? > >> > >> > >> Somebody could have a go at implementing this: > >> > >> https://bugs.gentoo.org/show_bug.cgi?id=390651 > >> > >> It's been brewing for half a decade. Maybe it's time. :) > >> > >> > >> Regards, > >> jer > >> > > > > With the new repoman code structure, yes, it would be a lot easier > > to implement. > > > > Also with the gen-b0rk test repo, that will be a good testing ground > > for eclass changes too. It just needs more devs to make test > > ebuilds to get it fully populated ;) > > > What sort of test ebuilds are you looking for? There are a few > packages I'd like to see get into Gentoo but I don't want to break > anything. :P > Have a look at the gen-b0rk repo, See how the ebuilds are done, follow those examples. There are lots more errors that repoman looks for that are not yet covered by test ebuilds. There are a few more in other areas of code, but here is the biggest list of errors/warnings that repoman can test for. https://gitweb.gentoo.org/proj/portage.git/tree/repoman/pym/repoman/qa_data.py?h=repoman -- Brian Dolbec <dolsen> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 951 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1460833703.ad0c2ab2bdbd34f4550e49c56cfd5974d6a2c07a.blueness@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1460833703.ad0c2ab2bdbd34f4550e49c56cfd5974d6a2c07a.blueness@gentoo> @ 2016-04-16 19:05 ` Michał Górny 2016-04-16 19:13 ` Anthony G. Basile ` (3 more replies) 0 siblings, 4 replies; 119+ messages in thread From: Michał Górny @ 2016-04-16 19:05 UTC (permalink / raw To: Anthony G. Basile; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1530 bytes --] On Sat, 16 Apr 2016 19:01:02 +0000 (UTC) "Anthony G. Basile" <blueness@gentoo.org> wrote: > commit: ad0c2ab2bdbd34f4550e49c56cfd5974d6a2c07a > Author: Anthony G. Basile <blueness <AT> gentoo <DOT> org> > AuthorDate: Sat Apr 16 19:08:23 2016 +0000 > Commit: Anthony G. Basile <blueness <AT> gentoo <DOT> org> > CommitDate: Sat Apr 16 19:08:23 2016 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad0c2ab2 > > ssl-cert.eclass: add libressl support > > eclass/ssl-cert.eclass | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass > index 002de76..2538f4d 100644 > --- a/eclass/ssl-cert.eclass > +++ b/eclass/ssl-cert.eclass > @@ -30,10 +30,10 @@ > > if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then > if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then > - DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )" > + DEPEND="${SSL_CERT_USE}? ( || ( dev-libs/openssl:0= dev-libs/libressl:0= ) )" > IUSE="${SSL_CERT_USE}" > else > - DEPEND="dev-libs/openssl:0=" > + DEPEND="|| ( dev-libs/openssl:0= dev-libs/libressl:0= )" > fi > fi > Congratulations! You've just committed an invalid dependency that is going to cause true mayhem on every package using the eclass. But why would anyone send patches for review, or even start wondering that we might be using USE=libressl all around for some reason... -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 19:05 ` Michał Górny @ 2016-04-16 19:13 ` Anthony G. Basile 2016-04-16 19:16 ` Rich Freeman ` (2 subsequent siblings) 3 siblings, 0 replies; 119+ messages in thread From: Anthony G. Basile @ 2016-04-16 19:13 UTC (permalink / raw To: gentoo-dev On 4/16/16 3:05 PM, Michał Górny wrote: > On Sat, 16 Apr 2016 19:01:02 +0000 (UTC) > "Anthony G. Basile" <blueness@gentoo.org> wrote: > >> commit: ad0c2ab2bdbd34f4550e49c56cfd5974d6a2c07a >> Author: Anthony G. Basile <blueness <AT> gentoo <DOT> org> >> AuthorDate: Sat Apr 16 19:08:23 2016 +0000 >> Commit: Anthony G. Basile <blueness <AT> gentoo <DOT> org> >> CommitDate: Sat Apr 16 19:08:23 2016 +0000 >> URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad0c2ab2 >> >> ssl-cert.eclass: add libressl support >> >> eclass/ssl-cert.eclass | 12 ++++++++---- >> 1 file changed, 8 insertions(+), 4 deletions(-) >> >> diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass >> index 002de76..2538f4d 100644 >> --- a/eclass/ssl-cert.eclass >> +++ b/eclass/ssl-cert.eclass >> @@ -30,10 +30,10 @@ >> >> if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then >> if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then >> - DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )" >> + DEPEND="${SSL_CERT_USE}? ( || ( dev-libs/openssl:0= dev-libs/libressl:0= ) )" >> IUSE="${SSL_CERT_USE}" >> else >> - DEPEND="dev-libs/openssl:0=" >> + DEPEND="|| ( dev-libs/openssl:0= dev-libs/libressl:0= )" >> fi >> fi >> > > Congratulations! You've just committed an invalid dependency that is > going to cause true mayhem on every package using the eclass. > > But why would anyone send patches for review, or even start wondering > that we might be using USE=libressl all around for some reason... > It was discussed on the bug report and I asked robbat2. Revert then. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 19:05 ` Michał Górny 2016-04-16 19:13 ` Anthony G. Basile @ 2016-04-16 19:16 ` Rich Freeman 2016-04-16 19:18 ` Anthony G. Basile 2016-04-16 19:27 ` Anthony G. Basile 2016-04-17 8:15 ` Fabian Groffen 3 siblings, 1 reply; 119+ messages in thread From: Rich Freeman @ 2016-04-16 19:16 UTC (permalink / raw To: gentoo-dev; +Cc: Anthony G. Basile On Sat, Apr 16, 2016 at 3:05 PM, Michał Górny <mgorny@gentoo.org> wrote: > > Congratulations! ... But why would anyone... Not really picking on you in particular, but this is not the first snarky comment on a commit we've seen today. If somebody makes a mistake, just point it out. I think we can all appreciate that glibc shouldn't break even in ~arch, and that libressl needs a USE flag due to the whole ABI situation. I can't remember the last time I just factually pointed out a mistake to somebody that they didn't just fix it. When there are real controversies then there are ways to escalate. We don't need to manufacture them out of accidents. -- Rich ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 19:16 ` Rich Freeman @ 2016-04-16 19:18 ` Anthony G. Basile 2016-04-16 19:41 ` Anthony G. Basile 0 siblings, 1 reply; 119+ messages in thread From: Anthony G. Basile @ 2016-04-16 19:18 UTC (permalink / raw To: Rich Freeman, gentoo-dev On 4/16/16 3:16 PM, Rich Freeman wrote: > On Sat, Apr 16, 2016 at 3:05 PM, Michał Górny <mgorny@gentoo.org> wrote: >> >> Congratulations! ... But why would anyone... > > Not really picking on you in particular, but this is not the first > snarky comment on a commit we've seen today. > > If somebody makes a mistake, just point it out. I think we can all > appreciate that glibc shouldn't break even in ~arch, and that libressl > needs a USE flag due to the whole ABI situation. > > I can't remember the last time I just factually pointed out a mistake > to somebody that they didn't just fix it. When there are real > controversies then there are ways to escalate. We don't need to > manufacture them out of accidents. > I know it will cause rebuild but we are moving towards openssl:0= dependency. Please look at the discussion on bug #569112. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 19:18 ` Anthony G. Basile @ 2016-04-16 19:41 ` Anthony G. Basile 0 siblings, 0 replies; 119+ messages in thread From: Anthony G. Basile @ 2016-04-16 19:41 UTC (permalink / raw To: gentoo-dev On 4/16/16 3:18 PM, Anthony G. Basile wrote: > On 4/16/16 3:16 PM, Rich Freeman wrote: >> On Sat, Apr 16, 2016 at 3:05 PM, Michał Górny <mgorny@gentoo.org> wrote: >>> >>> Congratulations! ... But why would anyone... >> >> Not really picking on you in particular, but this is not the first >> snarky comment on a commit we've seen today. >> >> If somebody makes a mistake, just point it out. I think we can all >> appreciate that glibc shouldn't break even in ~arch, and that libressl >> needs a USE flag due to the whole ABI situation. >> >> I can't remember the last time I just factually pointed out a mistake >> to somebody that they didn't just fix it. When there are real >> controversies then there are ways to escalate. We don't need to >> manufacture them out of accidents. >> > > I know it will cause rebuild but we are moving towards openssl:0= > dependency. Please look at the discussion on bug #569112. > Sorry I originally thought mgorny was referring to the added slot operators, but he meant the USE flags. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 19:05 ` Michał Górny 2016-04-16 19:13 ` Anthony G. Basile 2016-04-16 19:16 ` Rich Freeman @ 2016-04-16 19:27 ` Anthony G. Basile 2016-04-16 19:31 ` Anthony G. Basile 2016-04-17 8:15 ` Fabian Groffen 3 siblings, 1 reply; 119+ messages in thread From: Anthony G. Basile @ 2016-04-16 19:27 UTC (permalink / raw To: gentoo-dev On 4/16/16 3:05 PM, Michał Górny wrote: > On Sat, 16 Apr 2016 19:01:02 +0000 (UTC) > "Anthony G. Basile" <blueness@gentoo.org> wrote: Okay for review. Sorry for the wrap. diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass index 002de76..fc2debd 100644 --- a/eclass/ssl-cert.eclass +++ b/eclass/ssl-cert.eclass @@ -30,10 +30,10 @@ if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then - DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )" + DEPEND="${SSL_CERT_USE}? ( !libressl? ( dev-libs/openssl:0= ) libressl? ( dev-libs/librssl:0= ) )" IUSE="${SSL_CERT_USE}" else - DEPEND="dev-libs/openssl:0=" + DEPEND="!libressl? ( dev-libs/openssl:0= ) libressl? ( dev-libs/librssl:0= )" fi fi -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 19:27 ` Anthony G. Basile @ 2016-04-16 19:31 ` Anthony G. Basile 2016-04-16 22:24 ` Mike Gilbert 0 siblings, 1 reply; 119+ messages in thread From: Anthony G. Basile @ 2016-04-16 19:31 UTC (permalink / raw To: gentoo-dev On 4/16/16 3:27 PM, Anthony G. Basile wrote: > On 4/16/16 3:05 PM, Michał Górny wrote: >> On Sat, 16 Apr 2016 19:01:02 +0000 (UTC) >> "Anthony G. Basile" <blueness@gentoo.org> wrote: > > Okay for review. Sorry for the wrap. > > diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass > index 002de76..fc2debd 100644 > --- a/eclass/ssl-cert.eclass > +++ b/eclass/ssl-cert.eclass > @@ -30,10 +30,10 @@ > > if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then > if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then > - DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )" > + DEPEND="${SSL_CERT_USE}? ( !libressl? ( > dev-libs/openssl:0= ) libressl? ( dev-libs/librssl:0= ) )" > IUSE="${SSL_CERT_USE}" > else > - DEPEND="dev-libs/openssl:0=" > + DEPEND="!libressl? ( dev-libs/openssl:0= ) libressl? ( > dev-libs/librssl:0= )" > fi > fi > > > Actually the eclass also needs IUSE="${IUSE} libressl" -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 19:31 ` Anthony G. Basile @ 2016-04-16 22:24 ` Mike Gilbert 2016-04-16 22:36 ` Rich Freeman 0 siblings, 1 reply; 119+ messages in thread From: Mike Gilbert @ 2016-04-16 22:24 UTC (permalink / raw To: Gentoo Dev On Sat, Apr 16, 2016 at 3:31 PM, Anthony G. Basile <blueness@gentoo.org> wrote: > On 4/16/16 3:27 PM, Anthony G. Basile wrote: >> On 4/16/16 3:05 PM, Michał Górny wrote: >>> On Sat, 16 Apr 2016 19:01:02 +0000 (UTC) >>> "Anthony G. Basile" <blueness@gentoo.org> wrote: >> >> Okay for review. Sorry for the wrap. >> >> diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass >> index 002de76..fc2debd 100644 >> --- a/eclass/ssl-cert.eclass >> +++ b/eclass/ssl-cert.eclass >> @@ -30,10 +30,10 @@ >> >> if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then >> if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then >> - DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )" >> + DEPEND="${SSL_CERT_USE}? ( !libressl? ( >> dev-libs/openssl:0= ) libressl? ( dev-libs/librssl:0= ) )" >> IUSE="${SSL_CERT_USE}" >> else >> - DEPEND="dev-libs/openssl:0=" >> + DEPEND="!libressl? ( dev-libs/openssl:0= ) libressl? ( >> dev-libs/librssl:0= )" >> fi >> fi >> >> >> > > Actually the eclass also needs IUSE="${IUSE} libressl" As discussed in IRC, the slot-operator is unneeded, and has been removed. And I don't really see the point in the libressl USE flag in this case; I think that was only needed so the slot-operator would resolve correctly. My suggestion would be this: DEPEND="${SSL_CERT_USE}? ( || ( dev-libs/openssl:0 dev-libs/libressl:0 ) )" ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 22:24 ` Mike Gilbert @ 2016-04-16 22:36 ` Rich Freeman 2016-04-16 22:46 ` Mike Gilbert 2016-04-16 22:50 ` Anthony G. Basile 0 siblings, 2 replies; 119+ messages in thread From: Rich Freeman @ 2016-04-16 22:36 UTC (permalink / raw To: gentoo-dev On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert <floppym@gentoo.org> wrote: > > And I don't really see the point in the libressl USE flag in this > case; I think that was only needed so the slot-operator would resolve > correctly. > Somebody else may be better informed, but I thought that there was a concern with having both libressl and openssl linked into two libraries that are in turn linked to by something else (causing a symbol collision), and the USE flag was necessary to switch between the two implementations since they aren't virtualized. If we've solved that problem in some other way then by all means say so. However, I thought this was the main tradeoff in letting it use the same soname. -- Rich ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 22:36 ` Rich Freeman @ 2016-04-16 22:46 ` Mike Gilbert 2016-04-16 22:54 ` Anthony G. Basile 2016-04-16 22:50 ` Anthony G. Basile 1 sibling, 1 reply; 119+ messages in thread From: Mike Gilbert @ 2016-04-16 22:46 UTC (permalink / raw To: Gentoo Dev On Sat, Apr 16, 2016 at 6:36 PM, Rich Freeman <rich0@gentoo.org> wrote: > On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert <floppym@gentoo.org> wrote: >> >> And I don't really see the point in the libressl USE flag in this >> case; I think that was only needed so the slot-operator would resolve >> correctly. >> > > Somebody else may be better informed, but I thought that there was a > concern with having both libressl and openssl linked into two > libraries that are in turn linked to by something else (causing a > symbol collision), and the USE flag was necessary to switch between > the two implementations since they aren't virtualized. > > If we've solved that problem in some other way then by all means say > so. However, I thought this was the main tradeoff in letting it use > the same soname. This eclass doesn't build/link anything. It just calls /usr/bin/openssl. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 22:46 ` Mike Gilbert @ 2016-04-16 22:54 ` Anthony G. Basile 0 siblings, 0 replies; 119+ messages in thread From: Anthony G. Basile @ 2016-04-16 22:54 UTC (permalink / raw To: gentoo-dev On 4/16/16 6:46 PM, Mike Gilbert wrote: > On Sat, Apr 16, 2016 at 6:36 PM, Rich Freeman <rich0@gentoo.org> wrote: >> On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert <floppym@gentoo.org> wrote: >>> >>> And I don't really see the point in the libressl USE flag in this >>> case; I think that was only needed so the slot-operator would resolve >>> correctly. >>> >> >> Somebody else may be better informed, but I thought that there was a >> concern with having both libressl and openssl linked into two >> libraries that are in turn linked to by something else (causing a >> symbol collision), and the USE flag was necessary to switch between >> the two implementations since they aren't virtualized. >> >> If we've solved that problem in some other way then by all means say >> so. However, I thought this was the main tradeoff in letting it use >> the same soname. > > This eclass doesn't build/link anything. It just calls /usr/bin/openssl. > You still need to be able to tell the difference between dev-libs/{open,libre}ssl; # openssl version LibreSSL 2.2.6 # openssl version OpenSSL 1.0.2g 1 Mar 2016 -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 22:36 ` Rich Freeman 2016-04-16 22:46 ` Mike Gilbert @ 2016-04-16 22:50 ` Anthony G. Basile 1 sibling, 0 replies; 119+ messages in thread From: Anthony G. Basile @ 2016-04-16 22:50 UTC (permalink / raw To: gentoo-dev On 4/16/16 6:36 PM, Rich Freeman wrote: > On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert <floppym@gentoo.org> wrote: >> >> And I don't really see the point in the libressl USE flag in this >> case; I think that was only needed so the slot-operator would resolve >> correctly. >> > > Somebody else may be better informed, but I thought that there was a > concern with having both libressl and openssl linked into two > libraries that are in turn linked to by something else (causing a > symbol collision), and the USE flag was necessary to switch between > the two implementations since they aren't virtualized. > > If we've solved that problem in some other way then by all means say > so. However, I thought this was the main tradeoff in letting it use > the same soname. > I was reasoning along the lines of Mike when I first committed this. The eclass simply provides a series of functions for generating certs. It is sufficient that the `openssl` utility be present whether its provided by dev-libs/openssl or dev-libs/libressl. You're not linking against it so the ABI issue is a non-issue. As far as being able to tell the difference between the two, you can use `openssl version`. The slot operator was more subtle. I'm aware that := only means something in RDEPENDs but people do RDEPEND="${DEPEND} ..." often and so as a precaution, I included it. However, the scope of DEPEND does not cross the eclass-ebuild boundary and since there is no RDEPEND in that eclass, its wrong to have :0= there. :0 is sufficient. inherit() in ebuild.sh scrubs the value of DEPEND, so its not as simple as just "source". -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply [flat|nested] 119+ messages in thread
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-16 19:05 ` Michał Górny ` (2 preceding siblings ...) 2016-04-16 19:27 ` Anthony G. Basile @ 2016-04-17 8:15 ` Fabian Groffen 2016-04-17 8:28 ` Anthony G. Basile 3 siblings, 1 reply; 119+ messages in thread From: Fabian Groffen @ 2016-04-17 8:15 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 577 bytes --] On 16-04-2016 21:05:56 +0200, Michał Górny wrote: > Congratulations! You've just committed an invalid dependency that is > going to cause true mayhem on every package using the eclass. I assume you've taken proper actions to mitigate this. > But why would anyone send patches for review, or even start wondering > that we might be using USE=libressl all around for some reason... While I believe your point is right (patches for review), I think this style of communication is unnecessary. Thanks, Fabian -- Fabian Groffen Gentoo on a different level [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-17 8:15 ` Fabian Groffen @ 2016-04-17 8:28 ` Anthony G. Basile 2016-04-17 22:50 ` Anthony G. Basile 0 siblings, 1 reply; 119+ messages in thread From: Anthony G. Basile @ 2016-04-17 8:28 UTC (permalink / raw To: gentoo-dev On 4/17/16 4:15 AM, Fabian Groffen wrote: > On 16-04-2016 21:05:56 +0200, Michał Górny wrote: >> Congratulations! You've just committed an invalid dependency that is >> going to cause true mayhem on every package using the eclass. > > I assume you've taken proper actions to mitigate this. > >> But why would anyone send patches for review, or even start wondering >> that we might be using USE=libressl all around for some reason... > > While I believe your point is right (patches for review), I think this > style of communication is unnecessary. In case you haven't been following the other communications regarding the matter, the USE flag is not necessary here because ssl-cert.eclass does not involve any linking against openssl/libressl. So I'll be recommitting the original patch without the slot operator. The original patch is at https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/ssl-cert.eclass?id=7a4d6bd5fcb25d8381bc08e20ad6a5c1c80ad78f plus s/:0=/:0/ > > Thanks, > Fabian > -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-17 8:28 ` Anthony G. Basile @ 2016-04-17 22:50 ` Anthony G. Basile 2016-04-18 2:09 ` Luca Barbato 0 siblings, 1 reply; 119+ messages in thread From: Anthony G. Basile @ 2016-04-17 22:50 UTC (permalink / raw To: gentoo-dev, base-system On 4/17/16 4:28 AM, Anthony G. Basile wrote: > On 4/17/16 4:15 AM, Fabian Groffen wrote: >> On 16-04-2016 21:05:56 +0200, Michał Górny wrote: >>> Congratulations! You've just committed an invalid dependency that is >>> going to cause true mayhem on every package using the eclass. >> >> I assume you've taken proper actions to mitigate this. >> >>> But why would anyone send patches for review, or even start wondering >>> that we might be using USE=libressl all around for some reason... >> >> While I believe your point is right (patches for review), I think this >> style of communication is unnecessary. > > In case you haven't been following the other communications regarding > the matter, the USE flag is not necessary here because ssl-cert.eclass > does not involve any linking against openssl/libressl. So I'll be > recommitting the original patch without the slot operator. > > The original patch is at > > https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/ssl-cert.eclass?id=7a4d6bd5fcb25d8381bc08e20ad6a5c1c80ad78f > > plus s/:0=/:0/ > >> >> Thanks, >> Fabian >> > > mgorny suggested that i look for any EAPI=0 ebuild inheriting ssl-cert.eclass. I hacked up the following: import portage portdb = portage.db["/"]["porttree"].dbapi gentoo_repo_location = portdb.repositories["gentoo"].location for cp in portdb.cp_all(trees=[gentoo_repo_location]): for cpv in portdb.cp_list(cp, mytree=gentoo_repo_location): eapi, inherited = portdb.aux_get(cpv, ["EAPI", "INHERITED"], myrepo="gentoo") if eapi == '0' and 'ssl-cert' in inherited.split(): print(cpv) and found net-ftp/netkit-ftpd-0.17-r8. Its pretty ancient and belongs to base system. Does base-system object if I bump it to EAPI=5 before I commit the ssl-cert patch? I'll start stabilization too obviously. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2016-04-17 22:50 ` Anthony G. Basile @ 2016-04-18 2:09 ` Luca Barbato 0 siblings, 0 replies; 119+ messages in thread From: Luca Barbato @ 2016-04-18 2:09 UTC (permalink / raw To: Anthony G. Basile, gentoo-dev, base-system On 18/04/16 00:50, Anthony G. Basile wrote: > Does base-system object if I bump it to EAPI=5 before I commit the > ssl-cert patch? I'll start stabilization too obviously. > Please do. ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1448180855.a144d7480f781f21323943d87e6a56136add3830.mr_bones_@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1448180855.a144d7480f781f21323943d87e6a56136add3830.mr_bones_@gentoo> @ 2015-11-22 8:38 ` Michał Górny 0 siblings, 0 replies; 119+ messages in thread From: Michał Górny @ 2015-11-22 8:38 UTC (permalink / raw To: Michael Sterrett; +Cc: gentoo-dev, qa [-- Attachment #1: Type: text/plain, Size: 2711 bytes --] On Sun, 22 Nov 2015 08:27:47 +0000 (UTC) "Michael Sterrett" <mr_bones_@gentoo.org> wrote: > commit: a144d7480f781f21323943d87e6a56136add3830 > Author: Michael Sterrett <mr_bones_ <AT> gentoo <DOT> org> > AuthorDate: Sun Nov 22 08:26:57 2015 +0000 > Commit: Michael Sterrett <mr_bones_ <AT> gentoo <DOT> org> > CommitDate: Sun Nov 22 08:27:35 2015 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a144d748 > > Stop inheriting base.eclass (bug #494208) > > eclass/games.eclass | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/eclass/games.eclass b/eclass/games.eclass > index 7d231e1..aebf679 100644 > --- a/eclass/games.eclass > +++ b/eclass/games.eclass > @@ -24,11 +24,11 @@ > if [[ -z ${_GAMES_ECLASS} ]]; then > _GAMES_ECLASS=1 > > -inherit base multilib toolchain-funcs eutils user > +inherit multilib toolchain-funcs eutils user This changes API in all existing eclasses. In paricular, src_unpack() and src_prepare() stop being implicitly exported which can cause them to being implicitly replaced by another eclass. Which is especially relevant since you specifically required people to inherit games.eclass last and force its overrides. > case ${EAPI:-0} in > 0|1) EXPORT_FUNCTIONS pkg_setup src_compile pkg_preinst pkg_postinst ;; > - 2|3|4|5) EXPORT_FUNCTIONS pkg_setup src_configure src_compile pkg_preinst pkg_postinst ;; > + 2|3|4|5|6) EXPORT_FUNCTIONS pkg_setup src_configure src_compile pkg_preinst pkg_postinst ;; This is irrelevant change and belongs in a separate commit. Furthermore, I don't think it is appropriate to enable new EAPI support until you perform the eclass changes requested by the Council. > *) die "no support for EAPI=${EAPI} yet" ;; > esac > > @@ -302,12 +302,14 @@ games_src_configure() { > > # @FUNCTION: games_src_compile > # @DESCRIPTION: > -# Runs base_src_make(). This function is exported as src_compile(). > +# This function is exported as src_compile(). > games_src_compile() { > case ${EAPI:-0} in > 0|1) games_src_configure ;; > esac > - base_src_make > + if [[ -f Makefile || -f GNUmakefile || -f makefile ]]; then > + emake "$@" || die > + fi > } > > # @FUNCTION: games_pkg_preinst > I'm going to revert this commit on behalf of QA to avoid breakage. The relevant bug specifically mentioned making the change conditional to EAPI 6. Please either do that (and don't enable EAPI 6 until you have performed all requested changes), or confirm that none of the packages will be broken by removing it retroactively. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1447717075.aac24917ebe254a23990f0d7fff9f6f570b99d15.mpagano@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1447717075.aac24917ebe254a23990f0d7fff9f6f570b99d15.mpagano@gentoo> @ 2015-11-17 7:19 ` Michał Górny 2015-11-17 20:37 ` Raymond Jennings 2015-11-17 21:59 ` Mike Pagano 0 siblings, 2 replies; 119+ messages in thread From: Michał Górny @ 2015-11-17 7:19 UTC (permalink / raw To: Mike Pagano; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1769 bytes --] On Mon, 16 Nov 2015 23:38:08 +0000 (UTC) "Mike Pagano" <mpagano@gentoo.org> wrote: > commit: aac24917ebe254a23990f0d7fff9f6f570b99d15 > Author: Mike Pagano <mpagano <AT> gentoo <DOT> org> > AuthorDate: Mon Nov 16 23:37:55 2015 +0000 > Commit: Mike Pagano <mpagano <AT> gentoo <DOT> org> > CommitDate: Mon Nov 16 23:37:55 2015 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aac24917 > > kernel-2.eclass: Fix for git-sources 4.4_rcX > > eclass/kernel-2.eclass | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass > index 0f47b8c..5a9ea9f 100644 > --- a/eclass/kernel-2.eclass > +++ b/eclass/kernel-2.eclass > @@ -1079,9 +1079,9 @@ unipatch() { > # https://bugs.gentoo.org/show_bug.cgi?id=507656 # > #################################################################### > if [[ ${PN} == "git-sources" ]] ; then > - if [[ ${KV_MAJOR}${KV_PATCH} -ge 315 && ${RELEASETYPE} == -rc ]] ; then > + if [[ ${KV_MAJOR}.${KV_PATCH} > 3.15 && ${RELEASETYPE} == -rc ]] ; then Don't do string comparison on numbers. It can fail randomly, and teaches others who read it bad practices. For example, it would fail when kernel reaches version 10 ;-P. Instead: [[ ${KV_MAJOR} -gt 3 || ( ${KV_MAJOR} -eq 3 && ${KV_PATCH} -gt 15 ) ]] > ebegin "Applying ${i/*\//} (-p1)" > - if [ $(patch -p1 --no-backup-if-mismatch -f < ${i} >> ${STDERR_T}) "$?" -eq 0 ]; then > + if [ $(patch -p1 --no-backup-if-mismatch -f < ${i} >> ${STDERR_T}) "$?" -le 2 ]; then > eend 0 > rm ${STDERR_T} > break > -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-11-17 7:19 ` Michał Górny @ 2015-11-17 20:37 ` Raymond Jennings 2015-11-17 23:42 ` Rich Freeman 2015-11-17 21:59 ` Mike Pagano 1 sibling, 1 reply; 119+ messages in thread From: Raymond Jennings @ 2015-11-17 20:37 UTC (permalink / raw To: gentoo-dev; +Cc: Mike Pagano [-- Attachment #1: Type: text/plain, Size: 2694 bytes --] As a possibly relevant side note, I've observed how api changes are handled in the linux kernel: You can change whatever you want if it's a good idea, but as part of proving it, you have to be willing to take over the warranty for anything you break. So basically you change what you please ONLY if you also take the burden of fixing everything that depended on what you screwed with. Is this how things are handled by gentoo as well? On Mon, Nov 16, 2015 at 11:19 PM, Michał Górny <mgorny@gentoo.org> wrote: > On Mon, 16 Nov 2015 23:38:08 +0000 (UTC) > "Mike Pagano" <mpagano@gentoo.org> wrote: > > > commit: aac24917ebe254a23990f0d7fff9f6f570b99d15 > > Author: Mike Pagano <mpagano <AT> gentoo <DOT> org> > > AuthorDate: Mon Nov 16 23:37:55 2015 +0000 > > Commit: Mike Pagano <mpagano <AT> gentoo <DOT> org> > > CommitDate: Mon Nov 16 23:37:55 2015 +0000 > > URL: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aac24917 > > > > kernel-2.eclass: Fix for git-sources 4.4_rcX > > > > eclass/kernel-2.eclass | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass > > index 0f47b8c..5a9ea9f 100644 > > --- a/eclass/kernel-2.eclass > > +++ b/eclass/kernel-2.eclass > > @@ -1079,9 +1079,9 @@ unipatch() { > > # https://bugs.gentoo.org/show_bug.cgi?id=507656 > # > > > #################################################################### > > if [[ ${PN} == "git-sources" ]] ; then > > - if [[ ${KV_MAJOR}${KV_PATCH} -ge 315 && > ${RELEASETYPE} == -rc ]] ; then > > + if [[ ${KV_MAJOR}.${KV_PATCH} > 3.15 && > ${RELEASETYPE} == -rc ]] ; then > > Don't do string comparison on numbers. It can fail randomly, > and teaches others who read it bad practices. For example, it would > fail when kernel reaches version 10 ;-P. > > Instead: > > [[ ${KV_MAJOR} -gt 3 || ( ${KV_MAJOR} -eq 3 && ${KV_PATCH} -gt 15 ) ]] > > > ebegin "Applying ${i/*\//} (-p1)" > > - if [ $(patch -p1 > --no-backup-if-mismatch -f < ${i} >> ${STDERR_T}) "$?" -eq 0 ]; then > > + if [ $(patch -p1 > --no-backup-if-mismatch -f < ${i} >> ${STDERR_T}) "$?" -le 2 ]; then > > eend 0 > > rm ${STDERR_T} > > break > > > > > > -- > Best regards, > Michał Górny > <http://dev.gentoo.org/~mgorny/> > [-- Attachment #2: Type: text/html, Size: 3994 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-11-17 20:37 ` Raymond Jennings @ 2015-11-17 23:42 ` Rich Freeman 0 siblings, 0 replies; 119+ messages in thread From: Rich Freeman @ 2015-11-17 23:42 UTC (permalink / raw To: gentoo-dev; +Cc: Mike Pagano On Tue, Nov 17, 2015 at 3:37 PM, Raymond Jennings <shentino@gmail.com> wrote: > As a possibly relevant side note, I've observed how api changes are handled > in the linux kernel: > > You can change whatever you want if it's a good idea, but as part of proving > it, you have to be willing to take over the warranty for anything you break. > > So basically you change what you please ONLY if you also take the burden of > fixing everything that depended on what you screwed with. > > Is this how things are handled by gentoo as well? > For the most part, yes, though sometimes changes are posted well in advance with the goal of getting everybody to pitch in. This is why a change like this was implemented with an EAPI change. There is no retroactive impact of the change, so nothing in the tree is affected. Developers just have to fix their ebuilds before they move to the new EAPI. -- Rich ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-11-17 7:19 ` Michał Górny 2015-11-17 20:37 ` Raymond Jennings @ 2015-11-17 21:59 ` Mike Pagano 1 sibling, 0 replies; 119+ messages in thread From: Mike Pagano @ 2015-11-17 21:59 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 619 bytes --] On Tuesday, November 17, 2015 08:19:29 AM Michał Górny wrote: > On Mon, 16 Nov 2015 23:38:08 +0000 (UTC) > > "Mike Pagano" <mpagano@gentoo.org> wrote: > > commit: aac24917ebe254a23990f0d7fff9f6f570b99d15 > > Author: Mike Pagano <mpagano <AT> gentoo <DOT> org> <snip> Thanks for the review and feedback. Applied your suggestion. Mike -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpagano@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0x81F2B137&op=index [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1446206629.df8e399c9bac2dc30d7cf69c2462a81729a3ae69.jlec@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1446206629.df8e399c9bac2dc30d7cf69c2462a81729a3ae69.jlec@gentoo> @ 2015-10-30 17:20 ` Michał Górny 2015-10-31 7:06 ` Mike Frysinger 2015-11-01 7:15 ` Ian Delaney 0 siblings, 2 replies; 119+ messages in thread From: Michał Górny @ 2015-10-30 17:20 UTC (permalink / raw To: Justin Lecher; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1743 bytes --] On Fri, 30 Oct 2015 12:03:59 +0000 (UTC) "Justin Lecher" <jlec@gentoo.org> wrote: > commit: df8e399c9bac2dc30d7cf69c2462a81729a3ae69 > Author: Justin Lecher <jlec <AT> gentoo <DOT> org> > AuthorDate: Fri Oct 30 10:18:05 2015 +0000 > Commit: Justin Lecher <jlec <AT> gentoo <DOT> org> > CommitDate: Fri Oct 30 12:03:49 2015 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8e399c > > eclass: Use consistent place for then in if clause Excuse me but who are you exactly to take a random eclass and commit random style changes inside without even bothering to contact the author? Not to mention this commit message is incorrect as it doesn't state which eclass was modified. > > Signed-off-by: Justin Lecher <jlec <AT> gentoo.org> > > eclass/distutils-r1.eclass | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass > index 185dd4f..dbd27a7 100644 > --- a/eclass/distutils-r1.eclass > +++ b/eclass/distutils-r1.eclass > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() { > > _distutils-r1_disable_ez_setup > > - if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]] > - then > + if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]; then This was intentionally wrapped to stay within 72-column line width. Not saying the eclass is perfect in keeping text width, especially with others committing random changes to it, but that's no reason to introduce further offenders. > # create source copies for each implementation > python_copy_sources > fi > -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-10-30 17:20 ` Michał Górny @ 2015-10-31 7:06 ` Mike Frysinger 2015-10-31 8:08 ` Michał Górny 2015-11-01 7:15 ` Ian Delaney 1 sibling, 1 reply; 119+ messages in thread From: Mike Frysinger @ 2015-10-31 7:06 UTC (permalink / raw To: gentoo-dev; +Cc: Justin Lecher [-- Attachment #1: Type: text/plain, Size: 1826 bytes --] On 30 Oct 2015 18:20, Michał Górny wrote: > On Fri, 30 Oct 2015 12:03:59 +0000 (UTC) "Justin Lecher" wrote: > > commit: df8e399c9bac2dc30d7cf69c2462a81729a3ae69 > > Author: Justin Lecher <jlec <AT> gentoo <DOT> org> > > AuthorDate: Fri Oct 30 10:18:05 2015 +0000 > > Commit: Justin Lecher <jlec <AT> gentoo <DOT> org> > > CommitDate: Fri Oct 30 12:03:49 2015 +0000 > > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8e399c > > > > eclass: Use consistent place for then in if clause > > Excuse me but who are you exactly to take a random eclass and commit > random style changes inside without even bothering to contact > the author? your attitude is wrong and is a great example of why people in the project are hesitant to touch anything anymore > > Signed-off-by: Justin Lecher <jlec <AT> gentoo.org> > > > > eclass/distutils-r1.eclass | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass > > index 185dd4f..dbd27a7 100644 > > --- a/eclass/distutils-r1.eclass > > +++ b/eclass/distutils-r1.eclass > > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() { > > > > _distutils-r1_disable_ez_setup > > > > - if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]] > > - then > > + if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]; then > > This was intentionally wrapped to stay within 72-column line width. Not > saying the eclass is perfect in keeping text width, especially with > others committing random changes to it, but that's no reason to > introduce further offenders. Gentoo has never had a hard 80-col rule let alone 72-cols. forcing a wrap here makes no sense and the new version is an improvement. -mike [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-10-31 7:06 ` Mike Frysinger @ 2015-10-31 8:08 ` Michał Górny 2015-10-31 15:05 ` Gregory Woodbury 2015-11-10 23:53 ` Mike Frysinger 0 siblings, 2 replies; 119+ messages in thread From: Michał Górny @ 2015-10-31 8:08 UTC (permalink / raw To: Mike Frysinger; +Cc: gentoo-dev, Justin Lecher [-- Attachment #1: Type: text/plain, Size: 2450 bytes --] On Sat, 31 Oct 2015 03:06:21 -0400 Mike Frysinger <vapier@gentoo.org> wrote: > On 30 Oct 2015 18:20, Michał Górny wrote: > > On Fri, 30 Oct 2015 12:03:59 +0000 (UTC) "Justin Lecher" wrote: > > > commit: df8e399c9bac2dc30d7cf69c2462a81729a3ae69 > > > Author: Justin Lecher <jlec <AT> gentoo <DOT> org> > > > AuthorDate: Fri Oct 30 10:18:05 2015 +0000 > > > Commit: Justin Lecher <jlec <AT> gentoo <DOT> org> > > > CommitDate: Fri Oct 30 12:03:49 2015 +0000 > > > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8e399c > > > > > > eclass: Use consistent place for then in if clause > > > > Excuse me but who are you exactly to take a random eclass and commit > > random style changes inside without even bothering to contact > > the author? > > your attitude is wrong and is a great example of why people in the project > are hesitant to touch anything anymore > > > > Signed-off-by: Justin Lecher <jlec <AT> gentoo.org> > > > > > > eclass/distutils-r1.eclass | 3 +-- > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass > > > index 185dd4f..dbd27a7 100644 > > > --- a/eclass/distutils-r1.eclass > > > +++ b/eclass/distutils-r1.eclass > > > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() { > > > > > > _distutils-r1_disable_ez_setup > > > > > > - if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]] > > > - then > > > + if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]; then > > > > This was intentionally wrapped to stay within 72-column line width. Not > > saying the eclass is perfect in keeping text width, especially with > > others committing random changes to it, but that's no reason to > > introduce further offenders. > > Gentoo has never had a hard 80-col rule let alone 72-cols. forcing a wrap > here makes no sense and the new version is an improvement. For years, Gentoo was unable to make *any* *sane* *global* rules. Which doesn't mean everything needs to be as crappy as the overall Gentoo 'quality'. So what's this improvement exactly? 'I like this style better, so it's an improvement'? As I see it, it's a pointless, changing-nothing-really commit that causes huge cache regen for no good reason except someone's fancy. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-10-31 8:08 ` Michał Górny @ 2015-10-31 15:05 ` Gregory Woodbury 2015-11-10 23:53 ` Mike Frysinger 1 sibling, 0 replies; 119+ messages in thread From: Gregory Woodbury @ 2015-10-31 15:05 UTC (permalink / raw To: gentoo-dev Grammar and style police are everywhere! This week are they shooting themselves in the foot over some totally trivial and meaningless extra characters somewhere on a line? Is it a case of "#TriviaDoesntMatter"? AFAICT the limitations on line lengths are are ANCIENT holdovers from days of fixed lenght cards and glass-teletypes. Totally meaningless in today's terminal emulator in GUIs world. It is certainly laudable to keep text block widths reasonable. It is fact that it is easier to read text at 6 or 7 inches wide versus more than 8 inches. BUT, it is also clear that a *consistent* style is easier to read instead of needlessly varying styles in one document. As for "being hesitant to touch anything anymore"... Practically all of the FOSS projects have adopted rather stringent and ridiculuous requirements that programmers and other have to jump through hoops (of flame?) to prove their qualifications to do anything. Gentoo is maybe one of the more conservative about having to go through the motions in oder to qualify as a "developer" and, personally, I no longer have the time or inclination (at my age of 62) to do so, just so that my 50+ years of programming and typing can be subject to the arbitrary rules. I don't expect to be granted free access to the code base without some oversight, but a code review by one or more others before a commit would/should be more than adequate to exclude bugs and blunders from being introduced. Over the years I have done much for the FOSS movement, and I have posted some small tools and scripts that some may find usefull, and where possible I contribute via bugzilla. I much prefer Gentoo as a platform since it is still committed to allowing the users to make significant choices about the environment instead of imposing "one way" policies as some other projects have done. But seeing this little tempest merely convinces me that some folks still don't get the point that some things of a substative nature (such as correctness and choice) are of more importance than other things (like "style" or options.) Also, avoiding idiosyncratic changes that have unforseen or un-intended consequences should be coordinated with others before introduction to a stable system. -- G.Wolfe Woodbury redwolfe@gmail.com ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-10-31 8:08 ` Michał Górny 2015-10-31 15:05 ` Gregory Woodbury @ 2015-11-10 23:53 ` Mike Frysinger 2015-11-11 9:09 ` Michał Górny 1 sibling, 1 reply; 119+ messages in thread From: Mike Frysinger @ 2015-11-10 23:53 UTC (permalink / raw To: Michał Górny; +Cc: gentoo-dev, Justin Lecher [-- Attachment #1: Type: text/plain, Size: 2478 bytes --] On 31 Oct 2015 09:08, Michał Górny wrote: > On Sat, 31 Oct 2015 03:06:21 -0400 Mike Frysinger wrote: > > On 30 Oct 2015 18:20, Michał Górny wrote: > > > On Fri, 30 Oct 2015 12:03:59 +0000 (UTC) "Justin Lecher" wrote: > > > > --- a/eclass/distutils-r1.eclass > > > > +++ b/eclass/distutils-r1.eclass > > > > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() { > > > > > > > > _distutils-r1_disable_ez_setup > > > > > > > > - if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]] > > > > - then > > > > + if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]; then > > > > > > This was intentionally wrapped to stay within 72-column line width. Not > > > saying the eclass is perfect in keeping text width, especially with > > > others committing random changes to it, but that's no reason to > > > introduce further offenders. > > > > Gentoo has never had a hard 80-col rule let alone 72-cols. forcing a wrap > > here makes no sense and the new version is an improvement. > > For years, Gentoo was unable to make *any* *sane* *global* rules. Which > doesn't mean everything needs to be as crappy as the overall Gentoo > 'quality'. you forgot "imo". we've had commonly accepted standards that people generally kept to, some of which were more fuzzy than others. but we've never had a hard 80 col rule and claiming that 72 col is an improvement is pretty hard to swallow. there's no reasonable argument for such minimal restrictions in todays's world, and "it's always been that way" doesn't fly. > So what's this improvement exactly? 'I like this style better, so it's > an improvement'? As I see it, it's a pointless, changing-nothing-really > commit that causes huge cache regen for no good reason except someone's > fancy. one thing that has been consistent is cuddling of the initial command. we do not write: if foo then for x in 1 2 3 do while true do we have always written: if foo ; then for x in 1 2 3 ; do while true ; do as for "why consistency", i think your e-mail is a bit confused here. one on hand you beoman lack of official hard style rules while on the other claiming that none exist and being inconsistent is fine. as for cache regen due to changed eclasses, meh, that happens every day, and for eclasses more widely used than this. it's a non-issue considering the caches are generated on servers and distributed to users. -mike [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-11-10 23:53 ` Mike Frysinger @ 2015-11-11 9:09 ` Michał Górny 2015-11-11 14:42 ` Luca Barbato 0 siblings, 1 reply; 119+ messages in thread From: Michał Górny @ 2015-11-11 9:09 UTC (permalink / raw To: Mike Frysinger; +Cc: gentoo-dev, Justin Lecher [-- Attachment #1: Type: text/plain, Size: 2068 bytes --] On Tue, 10 Nov 2015 18:53:03 -0500 Mike Frysinger <vapier@gentoo.org> wrote: > On 31 Oct 2015 09:08, Michał Górny wrote: > > On Sat, 31 Oct 2015 03:06:21 -0400 Mike Frysinger wrote: > > > On 30 Oct 2015 18:20, Michał Górny wrote: > > > > On Fri, 30 Oct 2015 12:03:59 +0000 (UTC) "Justin Lecher" wrote: > > > > > --- a/eclass/distutils-r1.eclass > > > > > +++ b/eclass/distutils-r1.eclass > > > > > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() { > > > > > > > > > > _distutils-r1_disable_ez_setup > > > > > > > > > > - if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]] > > > > > - then > > > > > + if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]; then > > > > > > > > This was intentionally wrapped to stay within 72-column line width. Not > > > > saying the eclass is perfect in keeping text width, especially with > > > > others committing random changes to it, but that's no reason to > > > > introduce further offenders. > > > > > > Gentoo has never had a hard 80-col rule let alone 72-cols. forcing a wrap > > > here makes no sense and the new version is an improvement. > > > > For years, Gentoo was unable to make *any* *sane* *global* rules. Which > > doesn't mean everything needs to be as crappy as the overall Gentoo > > 'quality'. > > you forgot "imo". we've had commonly accepted standards that people generally > kept to, some of which were more fuzzy than others. but we've never had a hard > 80 col rule and claiming that 72 col is an improvement is pretty hard to > swallow. there's no reasonable argument for such minimal restrictions in > todays's world, and "it's always been that way" doesn't fly. How about this; my terminal barely fits 90 characters? Of course, I could then just shot arbitrarily at 90 but for 10 characters... I'd rather use the old standard 80. Minus 8 characters for friendly e-mail quoting, which is also kinda 'old standard'. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-11-11 9:09 ` Michał Górny @ 2015-11-11 14:42 ` Luca Barbato 0 siblings, 0 replies; 119+ messages in thread From: Luca Barbato @ 2015-11-11 14:42 UTC (permalink / raw To: gentoo-dev On 11/11/15 10:09, Michał Górny wrote: > I'd rather use the old standard 80. Minus 8 characters for friendly > e-mail quoting, which is also kinda 'old standard'. You can suggest as above, with this tone, and probably you would get some consensus. Personally I think 80col is nice since you can have three-way side by side diff in most of the current screens. You can deliver your point effectively w/out screaming and name calling. lu ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-10-30 17:20 ` Michał Górny 2015-10-31 7:06 ` Mike Frysinger @ 2015-11-01 7:15 ` Ian Delaney 1 sibling, 0 replies; 119+ messages in thread From: Ian Delaney @ 2015-11-01 7:15 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 30 Oct 2015 18:20:08 +0100 Michał Górny <mgorny@gentoo.org> wrote: > On Fri, 30 Oct 2015 12:03:59 +0000 (UTC) > "Justin Lecher" <jlec@gentoo.org> wrote: > > > commit: df8e399c9bac2dc30d7cf69c2462a81729a3ae69 > > Author: Justin Lecher <jlec <AT> gentoo <DOT> org> > > AuthorDate: Fri Oct 30 10:18:05 2015 +0000 > > Commit: Justin Lecher <jlec <AT> gentoo <DOT> org> > > CommitDate: Fri Oct 30 12:03:49 2015 +0000 > > URL: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8e399c > > > > eclass: Use consistent place for then in if clause > > Excuse me but who are you exactly to take a random eclass and commit > random style changes inside without even bothering to contact > the author? > Well, what's this? he selected a random eclass? Then he recklessly committed a random style change? To my observation, the lead recruiter specifically selected the distutils-r1 eclass, not some random one like base.eclass, and carefully edited a couple of lines to put "; then" at the end of a line as is done in most any ebuild. So how RANDOM is that? In fact it isn't, however you have no hesitation in taking him to task not only over its randomness which isn't, but that he had the gaul to do it at all. Was it not you who insisted that I assign a bug over the func distutils_install_for_testing and you insisted I assign it to the python team, not to you as I did. You lectured me to follow the rules stating that it belongs to the python herd / project / w/e which may be authored by its members any time in the future. It seems you want it both ways. jlec is not only a member of python team but he is high ranked. That exactly is who he is. > Not to mention this commit message is incorrect as it doesn't state > which eclass was modified. > This is in fact correct. > > > > Signed-off-by: Justin Lecher <jlec <AT> gentoo.org> > > > > eclass/distutils-r1.eclass | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass > > index 185dd4f..dbd27a7 100644 > > --- a/eclass/distutils-r1.eclass > > +++ b/eclass/distutils-r1.eclass > > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() { > > > > _distutils-r1_disable_ez_setup > > > > - if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! > > ${DISTUTILS_SINGLE_IMPL} ]] > > - then > > + if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! > > ${DISTUTILS_SINGLE_IMPL} ]]; then > > This was intentionally wrapped to stay within 72-column line width. > Not saying the eclass is perfect in keeping text width, especially > with others committing random changes to it, but that's no reason to > introduce further offenders. > there's that random again. Once and for all mgorny get off your high horse. > > # create source copies for each implementation > > python_copy_sources > > fi > > > > > - -- kind regards Ian Delaney -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1 iKYEARECAGYFAlY0u/1fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDdDQUM1OUY0ODkzMERBREU1NUQ1RjJBRkIy OEVDMjEzQjgwNzJCMEQACgkQso7CE7gHKw3xZQCgyQb6Tyuw73CiBHgxXm/bvPX7 L1EAn0UfLOZTERZpMJN1VQXIgb81AkE6 =yt+k -----END PGP SIGNATURE----- -- kind regards Ian Delaney ^ permalink raw reply [flat|nested] 119+ messages in thread
[parent not found: <1444389412.5220bb29741e1685b42a6312c0b7bf2821672040.aballier@gentoo>]
* [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ [not found] <1444389412.5220bb29741e1685b42a6312c0b7bf2821672040.aballier@gentoo> @ 2015-10-09 15:32 ` hasufell 2015-10-09 16:21 ` Alexis Ballier 0 siblings, 1 reply; 119+ messages in thread From: hasufell @ 2015-10-09 15:32 UTC (permalink / raw To: gentoo-dev, Alexis Ballier On 10/09/2015 01:17 PM, Alexis Ballier wrote: > commit: 5220bb29741e1685b42a6312c0b7bf2821672040 > Author: Alexis Ballier <aballier <AT> gentoo <DOT> org> > AuthorDate: Fri Oct 9 11:16:38 2015 +0000 > Commit: Alexis Ballier <aballier <AT> gentoo <DOT> org> > CommitDate: Fri Oct 9 11:16:52 2015 +0000 > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5220bb29 > > eclass: ros-catkin.eclass: Use cmake-utils_src_make instead of plain emake for src_test so that it works with ninja too. > Please try to use short summary lines and put more detailed description into the commit message after a newline, also see https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Example The prefix is also a bit uncommon, see https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_message_format Ofc, I will expect people to jump in and say "the council hasn't decided on that yet", but well... it mostly works fine and is not really controversial. ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-10-09 15:32 ` hasufell @ 2015-10-09 16:21 ` Alexis Ballier 2015-10-09 16:25 ` hasufell 0 siblings, 1 reply; 119+ messages in thread From: Alexis Ballier @ 2015-10-09 16:21 UTC (permalink / raw To: gentoo-dev On Fri, 9 Oct 2015 17:32:22 +0200 hasufell <hasufell@gentoo.org> wrote: > On 10/09/2015 01:17 PM, Alexis Ballier wrote: > > commit: 5220bb29741e1685b42a6312c0b7bf2821672040 > > Author: Alexis Ballier <aballier <AT> gentoo <DOT> org> > > AuthorDate: Fri Oct 9 11:16:38 2015 +0000 > > Commit: Alexis Ballier <aballier <AT> gentoo <DOT> org> > > CommitDate: Fri Oct 9 11:16:52 2015 +0000 > > URL: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5220bb29 > > > > eclass: ros-catkin.eclass: Use cmake-utils_src_make instead of > > plain emake for src_test so that it works with ninja too. > > > > > Please try to use short summary lines and put more detailed > description into the commit message after a newline, also see > https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Example > > The prefix is also a bit uncommon, see > https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_message_format yeah, got that wrong; thx; i tried to remember it as '$dir: message', which works in all but this case it seems :) > Ofc, I will expect people to jump in and say "the council hasn't > decided on that yet", but well... it mostly works fine and is not > really controversial. not sure if council approval is needed; uniformity and consistency is way more important than whatever syntax is used ^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ 2015-10-09 16:21 ` Alexis Ballier @ 2015-10-09 16:25 ` hasufell 0 siblings, 0 replies; 119+ messages in thread From: hasufell @ 2015-10-09 16:25 UTC (permalink / raw To: Alexis Ballier; +Cc: gentoo-dev On 10/09/2015 06:21 PM, Alexis Ballier wrote: >> Ofc, I will expect people to jump in and say "the council hasn't >> decided on that yet", but well... it mostly works fine and is not >> really controversial. > > not sure if council approval is needed; uniformity and consistency is > way more important than whatever syntax is used > I agree. There is https://bugs.gentoo.org/show_bug.cgi?id=561190 and https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:66 but as you can see it is mostly empty. ^ permalink raw reply [flat|nested] 119+ messages in thread
end of thread, other threads:[~2019-09-06 6:35 UTC | newest] Thread overview: 119+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <1447458773.ad4c142684afb096e8fff2937ae5c5c3385dd22e.mgorny@gentoo> 2015-11-16 9:01 ` [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ Alexis Ballier 2015-11-16 9:06 ` Justin Lecher (jlec) 2015-11-16 9:14 ` Alexis Ballier 2015-11-16 9:29 ` Justin Lecher (jlec) 2015-11-16 9:52 ` Alexis Ballier 2015-11-16 12:08 ` Rich Freeman [not found] <1567619929.63486fef43c2e0dee3b4128db18fd1a6b4bf9381.tupone@gentoo> 2019-09-04 18:59 ` Michał Górny 2019-09-04 22:30 ` David Seifert 2019-09-04 23:26 ` Thomas Deutschmann 2019-09-05 4:02 ` Michał Górny 2019-09-05 13:14 ` Thomas Deutschmann 2019-09-05 14:04 ` Gordon Pettey 2019-09-05 19:26 ` Kent Fredric 2019-09-05 19:28 ` James Le Cuirot 2019-09-05 19:47 ` Michał Górny 2019-09-05 19:49 ` Michael Everitt 2019-09-05 20:08 ` Kent Fredric 2019-09-05 20:16 ` Michał Górny 2019-09-05 22:47 ` Thomas Deutschmann 2019-09-06 3:45 ` Mike Gilbert 2019-09-06 6:35 ` Alfredo Tupone 2019-09-06 5:49 ` Michał Górny 2019-09-06 4:02 ` Mike Gilbert [not found] <1564451381.6f680e4fe73925ae130343e02adb416cb799ce7d.mattst88@gentoo> 2019-07-30 5:20 ` Michał Górny 2019-07-30 5:29 ` Matt Turner [not found] <1526675772.d780c05e4459175eb314c82de9f3b998e2b4fc6e.asturm@gentoo> 2018-05-18 21:53 ` Michał Górny [not found] <1515158020.1e09cba657ccb2b8e6fbcbeb28c5c593da2127eb.polynomial-c@gentoo> 2018-01-05 13:36 ` Michał Górny [not found] <1494961831.d1b05bcf81e5058c20615179fb83a90c45daa487.vapier@gentoo> 2017-05-16 19:20 ` Michał Górny 2017-05-16 19:36 ` Fabian Groffen 2017-05-21 14:02 ` Kent Fredric 2017-05-21 14:46 ` Martin Vaeth 2017-05-21 16:29 ` William Hubbs 2017-05-21 17:34 ` Michał Górny 2017-05-21 18:18 ` Martin Vaeth 2017-05-21 19:32 ` Kent Fredric 2017-05-21 20:38 ` M. J. Everitt 2017-05-21 23:28 ` M. J. Everitt 2017-05-21 17:46 ` Raymond Jennings 2017-05-22 1:13 ` Luis Ressel [not found] <1463773635.548f4ee19c6b0fe0d5e87e84a5a82c421229e0ce.johu@gentoo> 2016-05-20 19:55 ` Michał Górny [not found] <1462655928.66afcab271f65b97330e610040ad3acc1b812a03.hd_brummy@gentoo> 2016-05-07 21:25 ` Michał Górny 2016-05-07 21:48 ` Ryan Hill 2016-05-09 23:10 ` Doug Goldstein 2016-05-13 8:52 ` Ian Delaney 2016-05-14 9:55 ` Andreas K. Huettel 2016-05-14 11:35 ` Ciaran McCreesh 2016-05-14 11:55 ` M. J. Everitt 2016-05-14 15:04 ` Gordon Pettey 2016-05-14 16:53 ` Chí-Thanh Christopher Nguyễn 2016-05-14 16:59 ` M. J. Everitt 2016-05-14 17:06 ` Rich Freeman 2016-05-14 17:07 ` landis blackwell 2016-05-14 17:52 ` Rich Freeman 2016-05-14 19:21 ` M. J. Everitt 2016-05-14 20:23 ` Rich Freeman 2016-05-15 10:47 ` Daniel Campbell 2016-05-14 17:08 ` M. J. Everitt 2016-05-14 20:06 ` Andreas K. Huettel 2016-05-14 11:55 ` Aaron Bauman 2016-05-14 13:54 ` Rich Freeman 2016-05-14 23:40 ` Aaron Bauman 2016-05-14 23:48 ` Ciaran McCreesh 2016-05-15 0:23 ` Aaron Bauman 2016-05-15 1:04 ` Rich Freeman 2016-05-15 1:12 ` M. J. Everitt 2016-05-16 7:56 ` Ian Delaney 2016-05-16 8:20 ` Consus 2016-05-16 8:30 ` Aaron Bauman 2016-05-16 9:05 ` Ciaran McCreesh 2016-05-16 16:21 ` Andrew Savchenko 2016-05-16 16:32 ` Andreas K. Huettel 2016-05-15 0:59 ` Rich Freeman 2016-05-15 1:12 ` M. J. Everitt 2016-05-15 9:53 ` Ryan Hill 2016-05-15 11:04 ` Daniel Campbell 2016-05-15 22:55 ` Duncan 2016-05-15 23:07 ` Daniel Campbell 2016-05-16 0:12 ` M. J. Everitt 2016-05-15 18:43 ` Andreas K. Huettel 2016-05-15 10:29 ` Michał Górny 2016-05-15 11:16 ` Daniel Campbell 2016-05-15 22:46 ` Duncan 2016-05-15 23:19 ` Rich Freeman 2016-05-15 9:05 ` Jeroen Roovers 2016-05-15 9:15 ` Brian Dolbec 2016-05-15 11:18 ` Daniel Campbell 2016-05-15 14:27 ` Brian Dolbec [not found] <1460833703.ad0c2ab2bdbd34f4550e49c56cfd5974d6a2c07a.blueness@gentoo> 2016-04-16 19:05 ` Michał Górny 2016-04-16 19:13 ` Anthony G. Basile 2016-04-16 19:16 ` Rich Freeman 2016-04-16 19:18 ` Anthony G. Basile 2016-04-16 19:41 ` Anthony G. Basile 2016-04-16 19:27 ` Anthony G. Basile 2016-04-16 19:31 ` Anthony G. Basile 2016-04-16 22:24 ` Mike Gilbert 2016-04-16 22:36 ` Rich Freeman 2016-04-16 22:46 ` Mike Gilbert 2016-04-16 22:54 ` Anthony G. Basile 2016-04-16 22:50 ` Anthony G. Basile 2016-04-17 8:15 ` Fabian Groffen 2016-04-17 8:28 ` Anthony G. Basile 2016-04-17 22:50 ` Anthony G. Basile 2016-04-18 2:09 ` Luca Barbato [not found] <1448180855.a144d7480f781f21323943d87e6a56136add3830.mr_bones_@gentoo> 2015-11-22 8:38 ` Michał Górny [not found] <1447717075.aac24917ebe254a23990f0d7fff9f6f570b99d15.mpagano@gentoo> 2015-11-17 7:19 ` Michał Górny 2015-11-17 20:37 ` Raymond Jennings 2015-11-17 23:42 ` Rich Freeman 2015-11-17 21:59 ` Mike Pagano [not found] <1446206629.df8e399c9bac2dc30d7cf69c2462a81729a3ae69.jlec@gentoo> 2015-10-30 17:20 ` Michał Górny 2015-10-31 7:06 ` Mike Frysinger 2015-10-31 8:08 ` Michał Górny 2015-10-31 15:05 ` Gregory Woodbury 2015-11-10 23:53 ` Mike Frysinger 2015-11-11 9:09 ` Michał Górny 2015-11-11 14:42 ` Luca Barbato 2015-11-01 7:15 ` Ian Delaney [not found] <1444389412.5220bb29741e1685b42a6312c0b7bf2821672040.aballier@gentoo> 2015-10-09 15:32 ` hasufell 2015-10-09 16:21 ` Alexis Ballier 2015-10-09 16:25 ` hasufell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox