On 3 February 2018 at 11:28, H.Merijn Brand <h.m.br...@xs4all.nl> wrote:
> Breaking something up-river of say DBI will affect just 3 authors (the
> (co)maints), whereas it affect millions of people (the users).
>
> If some brave author maintains two or more up-river modules, it is
> still just one author, but uncountable users. (don't count core modules
> here, that would make it too hard).
>

This.

While a "don't allow people to game the river" mentality might be
useful for a *popularity* metric ( or an indirect sense of the CPAN
authors web of trust ), its not a safe metric for deciding "what is
worth testing".

The darkpan plays a serious role here.

There is very little "real" software on CPAN, only libraries. All the
actual applications of the CPAN libraries operates outside of the
realm of CPAN.

And there is no way to tell how many hidden users exist of a given CPAN module.

All software on CPAN is subsequently "relevant" for testing, and the
only way you should use this graph is to *prioritize* which modules
you'll test first.

Though you should still be encouraged to test all modules, because
they can all become broken due to domino effects, and there is still
the high chance of there being some real world user who is using a
"less popular" module.

Or would you argue that something like App::DuckPAN is "Ok to break
because it doesn't have any reverse dependencies"?

And its quite easy to find other unarguably high-use things on CPAN
which due to how they work, are *unlikely* to have reverse
dependencies.

Take for instance, cpanm-reporter .

It would be quite easy to imagine a reality where the 2 reverse
dependencies it currently has never came to exist. But its clearly not
the sort of thing you want to wave your hand at as being unworthy of
testing. ( Because its quite obvious there are far more people who are
CPAN authors, actually use it, than there are reverse dependencies )

The river is subsequently not any kind of *authority* on what is
actually being used. Its just a convenient-yet-inferior approximation.
Its better than nothing, but please don't let yourself interpret it as
being more than it is.


KENTNL - https://metacpan.org/author/KENTNL

Reply via email to