Re: [gentoo-dev] stabilizing libraries without testing reverse deps

[Kent Fredric]

On 3 October 2013 05:43, yac <yac@g.o> wrote:

> I'd be cautious about involving users in this as it very often happens
> to myself that something breaks, I get mad and then figure it was my
> own fault (eg. messing with cflags I shouldn't mess with)
>

That does happen from time to time on the CPAN Testers network, the great
thing about this is though, that there exists a test report, user err or
not.

And it is the job of the person who manually looks into bug reports to
determine if they're a clear indication of a real bug being exhibited, or
if its a user configuration problem.

And if a CPAN Author wants, they can contact a sender and ask for more
context if the CPAN author feels it relevant.

This is basically an inversion of bug reporting mechanics in cases of
trivial accidents user side that might otherwise simply not get reported,
because it becomes the developers duty to follow up on a failed build if
they think its relevant.

Also, it helps with the bug reporting process, and helps users diagnose
their own bugs, because they can, upon seeing a test/build failure, check
the bug tracker *and* the report matrix, and see if other users are also
exihibiting the failure, to help them get an idea of what is causing the
failure, by comparing reported variables.

Then, a user can say "Oh look, see, there's a boat load of tests failing on
x86 with only this specific USE flag, there's no open bug for that, so I'll
open one, and give the maintainer a lot of context on what looks to be the
problem by linking directly to a handful of failed reports".

This, would also be incidentally convenient for that old "ANSI Term Escape
codes" problem, because the report/log submission would be automated (
giving us full control over how reports are performed ), and we could have
a custom interface for displaying such reports that handled any submitted
escape codes graciously, decoupling us from needing to find a way to handle
that problem in bugzilla.

Just the unfortunate part here is there are no off-the-shelf products for
this problem space, so somebody would have to develop one.

-- 
Kent