Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[Michał Górny]

On Mon, 2020-04-20 at 16:04 -0500, William Hubbs wrote:
> Your proposal seems to completely go against how the go ecosystem operates,
> but if you can come up with a proof-of-concept for how it would work
> without forcing a lot of busy work on us that would never get accepted
> upstream, I'll take a look.
>

Define 'busy work'.

Is doing things right 'busy work' vs taking shortcuts?  Is it 'busy
work' that I'm putting a lot of effort into fixing Python packages? 
Should I just last rite them all and tell people to use virtualenv?

Is testing packages 'busy work'?  I suppose it's all easier when you
just silently include 240 dependencies without testing a single one of
them and call it a day.  Sure, you run some tests on the final package. 
Leaves 240 untested, some of them likely failing tests and requiring
'busy work' to fix them.

Is security support 'busy work'?  I suppose it's all easier when you
ignore them problem and let security team deal with it (except they
won't).  Sure, you can assume that when vulnerability is discovered, all
upstreams will eventually learn of it, update their bundled dependencies
and *maybe* inform people that their code might have been indirectly
vulnerable (but would they do the 'busy work' of discovering whether it
affected them or not?).

I realize Go is not isolated here.  It's just brought as one major
example.  Rust is no better.  All these shiny 'write and forget'
languages share the same problem.  Pay for some work hours, get
a working product, deploy it and forget unless customers want more
features.

Today these languages are still young and the problems can be considered
largely theoretical.  But some day -- well, unless all the cool kids
manage to move on to next shiny new language before then -- this will be
a major catastrophe.

-- 
Best regards,
Michał Górny