Adam Kennedy wrote:
> Part of the problem comes in defining "bogus".
This is a red herring. Consider the original proposal:
If a tester sends in a 'updated' report (matching all the appropriate
criteria), then the update should overwrite/mask the original.
There is no need to define the criteri
On 3/14/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
>
> > Even better would be adding two more states so that you can
> > distinguish between prereq-failure, build-failure, test-failure and
> > ok.
>
> Well actually I tried to sit down the other day and work out how many
> distinct types of success
On Tue, Mar 14, 2006 at 23:04:02 +1100, Adam Kennedy wrote:
>
> >Even better would be adding two more states so that you can
> >distinguish between prereq-failure, build-failure, test-failure and
> >ok.
>
> Well actually I tried to sit down the other day and work out how many
> distinct types of
Even better would be adding two more states so that you can
distinguish between prereq-failure, build-failure, test-failure and
ok.
Well actually I tried to sit down the other day and work out how many
distinct types of success/failure events there might be, for use in PITA.
The number came
On 3/14/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> It's just that the reporting system has a very limited view of what
> should be stamped green, and what should be stamped red.
I've never like such breakdowns. Even adding only one more state/color
can make it a lot easier to interpret a result
* Adam Kennedy <[EMAIL PROTECTED]> [2006-03-14 05:15]:
>Part of the problem comes in defining "bogus".
I mean reports about tests which failed because the test box
didn’t have the prerequisites installed and didn’t bother trying
to either, or where the failed dependency is non-Perl, and so
couldn’
On Monday 13 March 2006 20:08, Adam Kennedy wrote:
> I know of at least a few developers that would consider a report to be
> bogus if one of their dependencies cannot install. Now personally, I
> consider that a failure on the part of BOTH of them.
>
> One for failing, and the other for adding a
A. Pagaltzis wrote:
* David Golden <[EMAIL PROTECTED]> [2006-03-13 23:05]:
This issue also has frustrated me for some time, but I don't
think that we should be considering deleting reports. Reports
are just facts -- they have no value basis. Yes, people may make
judgments about the robustness o
A. Pagaltzis wrote:
* David Golden <[EMAIL PROTECTED]> [2006-03-13 23:05]:
This issue also has frustrated me for some time, but I don't
think that we should be considering deleting reports. Reports
are just facts -- they have no value basis. Yes, people may make
judgments about the robustness o
* David Golden <[EMAIL PROTECTED]> [2006-03-13 23:05]:
>This issue also has frustrated me for some time, but I don't
>think that we should be considering deleting reports. Reports
>are just facts -- they have no value basis. Yes, people may make
>judgments about the robustness of a module based on
On Mon, Mar 13, 2006 at 14:31:53 -0700, Jerry D. Hedden wrote:
> Today, I filed a bug report against CPANPLUS because it
> sometimes fails to detect missing prerequisites, resulting
> in bogus FAIL reports being generated against modules:
>http://rt.cpan.org/Ticket/Display.html?id=18144
> Here
Moin,
On Monday 13 March 2006 23:01, David Golden wrote:
> Jerry D. Hedden wrote:
> > In addition to getting CPANPLUS fixed, I feel there is the
> > issue of what to do about such fallacious reports in the
> > CPAN Testers database. Currently, there is no functionality
> > for deleting such repor
Jerry D. Hedden wrote:
In addition to getting CPANPLUS fixed, I feel there is the
issue of what to do about such fallacious reports in the
CPAN Testers database. Currently, there is no functionality
for deleting such reports.
This issue also has frustrated me for some time, but I don't think t
Today, I filed a bug report against CPANPLUS because it
sometimes fails to detect missing prerequisites, resulting
in bogus FAIL reports being generated against modules:
http://rt.cpan.org/Ticket/Display.html?id=18144
Here are two examples of such failures:
http://www.nntp.perl.org/group/perl
14 matches
Mail list logo
