| 1 |
On Wed, 8 May 2019 11:08:47 -0700 |
| 2 |
Matt Turner <mattst88@g.o> wrote: |
| 3 |
|
| 4 |
> On Wed, May 8, 2019 at 3:19 AM Alexis Ballier <aballier@g.o> |
| 5 |
> wrote: |
| 6 |
> > |
| 7 |
> > On Wed, 08 May 2019 12:01:21 +0200 |
| 8 |
> > Michał Górny <mgorny@g.o> wrote: |
| 9 |
> > |
| 10 |
> > > On Wed, 2019-05-08 at 11:54 +0200, Alexis Ballier wrote: |
| 11 |
> > > > On Wed, 08 May 2019 11:41:41 +0200 |
| 12 |
> > > > Michał Górny <mgorny@g.o> wrote: |
| 13 |
> > > > |
| 14 |
> > > > > > There's multilib that adds a lot of flags with a single |
| 15 |
> > > > > > eclass change, but I'd guess the number of packages and |
| 16 |
> > > > > > flags is constantly growing, so sooner or later you'll be |
| 17 |
> > > > > > hit by this again and no multilib killing will help you |
| 18 |
> > > > > > then. |
| 19 |
> > > > > > |
| 20 |
> > > > > > I think it is more future proof to use the addition of |
| 21 |
> > > > > > multilib flags to fix pkgcheck rather than actively |
| 22 |
> > > > > > reducing the number of multilib flags to cope with its |
| 23 |
> > > > > > limitations. |
| 24 |
> > > > > |
| 25 |
> > > > > Then please do it, by all means. The reality is simple. If |
| 26 |
> > > > > the tool is broken, you either fix it or stop doing what you |
| 27 |
> > > > > know that breaks it. Being unable to do the former, and |
| 28 |
> > > > > having no good replacement, I'd go for the latter. |
| 29 |
> > > > |
| 30 |
> > > > Well, why is it slow ? IO ? CPU ? Did you collect profiling |
| 31 |
> > > > data ? |
| 32 |
> > > |
| 33 |
> > > CPU definitely. More detail than that, I don't and I don't have |
| 34 |
> > > time to investigate. |
| 35 |
> > |
| 36 |
> > So you don't have time to change 3 lines to add cProfile but do have |
| 37 |
> > time to send various emails and rework the entire multilib system ? |
| 38 |
> > weird. |
| 39 |
> |
| 40 |
> This isn't productive. |
| 41 |
> |
| 42 |
> If you'd like to do the work you're suggesting, I'm sure Michał will |
| 43 |
> support that, but as is you're just passive-aggressively questioning |
| 44 |
> his choices in the regards to the multilib system he created and the |
| 45 |
> CI system he created. |
| 46 |
> |
| 47 |
|
| 48 |
|
| 49 |
You're right about the passive-aggressive part, sorry about it. But |
| 50 |
maybe there's a single not so important check that's killing the |
| 51 |
performance and could be, instead, disabled meanwhile. No data has been |
| 52 |
shown except that adding useflags to packages make CI explode. |
| 53 |
I am indeed questioning the choices of making tree wide changes because |
| 54 |
a CI system is under performing and see nothing wrong about this. |
Archives