One of the goals of the CPAN River model is to get us to focus on cleaning up
the river, starting at the headwaters first. To that end, I’ve been thinking
about how we might measure “river quality”, and have written up two ideas so
far:
http://neilb.org/2015/05/11/measuring-cpan-quality
On 11 May 2015 at 12:37, Neil Bowers wrote:
> These are pretty simple, and have some problems, so I’m hoping someone
> might come up with something more useful.
Random thought while reading: backflow could be a thing to check for.
Some dists don't have tests, and still have deps, causing a fal
On Sun, May 10, 2015 at 8:37 PM, Neil Bowers
wrote:
>
> These are pretty simple, and have some problems, so I’m hoping someone
> might come up with something more useful.
>
It's really hard to examine specific cases with CT down at the moment, but
I think we could be considering a number of dime
> On 11 May 2015, at 01:47, Kent Fredric wrote:
> So the quality of a dist could be measured indirectly by the failure rate of
> its dependents.
This was kind of the basis of the “River Smoker” idea that Tux and and I
discussed late on the last day of the QAH:
http://neilb.org/2015/04/
On 11 May 2015 at 19:20, Neil Bowers wrote:
> look at 2 or more CPAN Testers fails where the only difference is an
> upriver version number.
my point didn't pertain to upriver versions changing, but the observation
that upriver modules can have buggy code that is only broken on certain
architec
> I think we could be considering a number of dimensions. Brainstorming:
>
> * fails tests now – i.e. blocking automated dep installations – this is your
> existing metric
> * possibly an OS-specific variation of the above
> * stability over time – possibly your existing metric, but taking last
6 matches
Mail list logo
