The problem is that that as modules use more and more dependencies, the
probability of successfully installing a modules is declining fast. because
a lot of modules (even some of the very basic once) have a small percentage
of test failure, and these are adding up.
I wouldn't have brought that up if not for the fact that recently, when I
install a new module, I almost expect to see a dependency fail and move to
debug mode.
David Cantrell told me that test that fail because an dependency failed to
install are discarded. this is not a test failure, and so no need to report
it. the module didn't fail. It *correctly* didn't install.
I disagree. A failure to install is a bug.
as a module user I don't really care why it failed to install - it is as
unusable to me as any other problem.
as a module author, I would like to know if my dependencies are not
dependable.
Of course, visiting the deps site can show this information, but if the
author isn't aware of the problem, why would he visit it?
Of course, I can decide that I don't care. similar to one of my modules
that fail on Perl 5.6, and I don't really care about that version, so I
ignored them.
It was said in the original discussion that the failure, if marked as one,
should be flagged differently then the regular pass / fail / na / unknown.
depfail was suggested.
And finally, if a module author upload a new version, and this new version
have test failure, I think that it is possible to notify the authors of
modules that depend on it without spamming them, but it is really tricky.
Thanks for listening, and thanks for the CPAN testers reports.
On Thu, Nov 8, 2012 at 8:28 PM, Shmuel Fomberg <shmuelfomb...@gmail.com> wrote:
> I disagree. A failure to install is a bug.
I respect your position, but this has been debated ad nauseum over the years.
The general consensus is that CPAN Testers exists to see if
distributions *build* and *test* correctly. Distributions that
correctly specify prerequisites are providing a contract: "if these
are available, then I will work". Therefore, when those prerequisites
are not available, we do not consider it a valid test of the contract
because the preconditions weren't met.
Frankly, even a new "depfail" grade isn't terribly helpful to end
users because the user has no idea if dependencies would fail for them
without trying them. Did it fail because the dependency is
fundamentally broken? Or only on that platform/perl? Or was an
external library involved? Or did the dependency fail because it has
some network test that timed out?
There are so many reasons that dependencies could fail that I think a
"depfail" grade winds up just being noise.
David Golden <x...@xdg.me> writes:
> On Thu, Nov 8, 2012 at 8:28 PM, Shmuel Fomberg <shmuelfomb...@gmail.com> wrote:
>> I disagree. A failure to install is a bug.
> I respect your position
I also understand Shmuel's position, ...
> , but this has been debated ad nauseum over the years. The general
> consensus is that CPAN Testers exists to see if distributions *build*
> and *test* correctly.
... and I also agree with that.
However, to me it's not clear whether Shmuel had actually new solutions
in mind.
So just for the archives, one *could* for instance simply render the
"Chance of all tests passing" from http://deps.cpantesters.org into the
metacpan overview page. Then again it's not clear whether that
information is worth to be that prominent because all arguments on
http://deps.cpantesters.org/static/overall-chance.html apply. And
obviously "someone with tuits"(TM) aka. "someone else"(R) has to
actually do that. Maybe a task for a metacpan contributor...
> On 9 Nov 2012, at 01:28, Shmuel Fomberg <shmuelfomb...@gmail.com> wrote:
> And finally, if a module author upload a new version, and this new version
> have test failure, I think that it is possible to notify the authors of
> modules that depend on it without spamming them, but it is really tricky.
That's not particularly difficult. CPANdeps already has all the required info, as it has reverse deps too - that is, it can also report on which modules depend on any particular module as well as what dependencies a module has. Using that info to spot failures in your prerequisites should be a fairly simple patch to the scripts that import the cpan-testers data. Just need a web by interface for authors to sign up (probably per dist as well as per author) and some way of keeping track of which dist/version failures have been reported to who. Finally, a link from the reverse deps page to lists of reports.
Patches welcome!
-- David Cantrell
This electrogram was despatched by wireless field telegraph. I would therefore ask that the recipient be so kind as to excuse any failures of courtesy or linguistic inelegance as an unfortunate side-effect of the technology.
> Frankly, even a new "depfail" grade isn't terribly helpful to end
> users because the user has no idea if dependencies would fail for them
> without trying them.
B-b-b-b-but .... as a module *owner*, how do I tell (from the tester reports) whether my module is failing to install simply because a dependency is failing to install ?
If my module is failing to install for that reason, then I think this should be made apparent ... without my having to actually *peruse* all of the reports.
(Actually, "should be made apparent" is probably a bit too strong - but I would regard it as a welcome improvement if such a feature were to be added).
Shmuel Fomberg <shmuelfomb...@gmail.com> writes:
> I disagree. A failure to install is a bug.
In principle, yes, but...
> as a module user I don't really care why it failed to install - it is as
> unusable to me as any other problem.
> as a module author, I would like to know if my dependencies are not
> dependable.
This reasoning is correct, the question is how to deal with it. The
single outstanding problem with this aspect of the dependency chain is
the multi dimensional version dependency. A module with 64 direct and
indirect dependencies is not rare. And the dependencies may all have
had, say, 16 different versions on cpan. Gives easily 1024 ways to fail
on a dependency. And among these there is a plentitude of irrelevant
combinations.
Or, as David Golden has put it: noise.
> Of course, visiting the deps site can show this information, but if the
> author isn't aware of the problem, why would he visit it?
I would ask the corresponding question to you: what is it that stops you
from reporting to the author via RT?
> Of course, I can decide that I don't care. similar to one of my modules
> that fail on Perl 5.6, and I don't really care about that version, so I
> ignored them.
> It was said in the original discussion that the failure, if marked as one,
> should be flagged differently then the regular pass / fail / na / unknown.
> depfail was suggested.
I have doubts this would be the right approach. I don't know how to do
it right but I would suggest as a start you report some of these
problems with the appropriate amount of detail in RT to the authors and
let us know about the tickets. If we see enough such user stories, maybe
we can invent something appropriate. Doing the right thing automatically
requires some exercise beforehand. Try to do it right manually and we
will probably see.
> And finally, if a module author upload a new version, and this new version
> have test failure, I think that it is possible to notify the authors of
> modules that depend on it without spamming them, but it is really tricky.
Fill the bugtrackers and keep track of the tickets yourself, so we can
learn from the experience.
On Sun, Nov 11, 2012 at 4:51 PM, Andreas Koenig wrote:
> > as a module user I don't really care why it failed to install - it is as
> > unusable to me as any other problem.
> > as a module author, I would like to know if my dependencies are not
> > dependable.
> This reasoning is correct, the question is how to deal with it. The
> single outstanding problem with this aspect of the dependency chain is
> the multi dimensional version dependency. A module with 64 direct and
> indirect dependencies is not rare. And the dependencies may all have
> had, say, 16 different versions on cpan. Gives easily 1024 ways to fail
> on a dependency. And among these there is a plentitude of irrelevant
> combinations.
> Or, as David Golden has put it: noise.
Most of the modules does not change frequently, and isn't that what cpan
testers are about - to test multiple combinations?
> > Of course, visiting the deps site can show this information, but if the
> > author isn't aware of the problem, why would he visit it?
> I would ask the corresponding question to you: what is it that stops you
> from reporting to the author via RT?
I did that. Again and again. but can't I just install modules and expect
them to work? I'm growing tired of that.
> And finally, if a module author upload a new version, and this new
> version
> > have test failure, I think that it is possible to notify the authors of
> > modules that depend on it without spamming them, but it is really tricky.
> Fill the bugtrackers and keep track of the tickets yourself, so we can
> learn from the experience.
Let's take as a sample case Test::Class. It have a meaningless test fail, a
patch waiting in the RT, and a lot of modules depending on it.
How can I find the list of modules that directly depend on it? metacpan's
reverse-dep give indirect deps too.
I will file a bug to all of them, and let's see what will happen.
Shmuel Fomberg <shmuelfomb...@gmail.com> writes:
> On Sun, Nov 11, 2012 at 4:51 PM, Andreas Koenig wrote:
>> > as a module user I don't really care why it failed to install - it is as
>> > unusable to me as any other problem.
>> > as a module author, I would like to know if my dependencies are not
>> > dependable.
>> This reasoning is correct, the question is how to deal with it. The
>> single outstanding problem with this aspect of the dependency chain
>> is the multi dimensional version dependency. A module with 64 direct
>> and indirect dependencies is not rare. And the dependencies may all
>> have had, say, 16 different versions on cpan. Gives easily 1024 ways
>> to fail on a dependency. And among these there is a plentitude of
>> irrelevant combinations. Or, as David Golden has put it: noise.
> Most of the modules does not change frequently,
That's a wrong assumption. Might apply for single cases but not in
general.
> and isn't that what cpan testers are about - to test multiple
> combinations?
And they are only comprehensible because they are in 2 dimensions.
What you want adds new dimensions, a hypercube of the test matrix.
That's where noise starts.
> Let's take as a sample case Test::Class. It have a meaningless test
> fail, a patch waiting in the RT, and a lot of modules depending on it.
> How can I find the list of modules that directly depend on it?
> metacpan's reverse-dep give indirect deps too. I will file a bug to
> all of them, and let's see what will happen.
That's a great example, really. Because you already *have* the issue and
patch available.
Why would you inform all the dependent modules if the root cause is
already known? From a single RT ticket which needs to be pushed you want
to multiply that onto all affected modules?
By that rationale a bug in a Perl core module would require a ticket in
all 20_000 CPAN distros.
Better ask the author of the stalled ticket about co-maintainership or
help him otherwise to bring that issue forward, eg. test it on your own
in several combinations, document the results in the ticket, do that
again with other prominent dependent modules, etc.
> And they are only comprehensible because they are in 2 dimensions.
> What you want adds new dimensions, a hypercube of the test matrix.
> That's where noise starts.
I understand that it is not needed to see all install failures for all
possible permutations of module versions. I think it IS very good
information to see if your module fails to install because of the
latest versions of CPAN modules are giving issues. So if an upstream
module gives test failures on some platforms, this can be very good
info for a module author. One of the possibilities would then be to
fix the upstream module, or of course you can choose to see if you can
do without the dependency, or select an alternate one.
The same for when one of the upstream modules start changing and
introduce failures in the chain. As a downstream module author, this
might be very interesting news, but in the current situation you would
not see this.
For instance about six weeks ago, the Variable::Magic module started
to give test failures. As a result, DBIx::Class was not installable
from CPAN. As a DBIx::Class author or if you're interested in the
module, this would be very good information I think.
<rant>Of course, for this to work, it test reports should be visible
at all in the first place! The XML::Compile::WSS module last visible
tests are from 1.01.
http://www.cpantesters.org/distro/X/XML-Compile-WSS.html#XML-Compile-... - 1.02 or later, released on October 22nd, does not have any visble
test reports! This is not because they have not been submitted, but
because they are not visible on the cpan-testers website. According to
the CPAN testers leaderboard, no tests in November have been submitted
at all. I reported this earlier in September; I (and more people)
offered help before. I run a smoker on a VPS for which I pay money. At
this time it does not seem to be a wise investment. At the moment I
think there are only a couple of options: either you (dagolden and
barbie) fix the cpan-testers website soon(ish) and yes I do understand
you are busy, or you allow other people to help fix the issue maybe
even by using the alternative put in place by Slaven, or people like
me will start losing interest and turn off their smokers. I think this
is very bad for the project.</rant>
On Sun, Nov 11, 2012 at 9:19 PM, Barbie <bar...@missbarbell.co.uk> wrote:
>> <rant>
> Really? Thanks for your support!
> Read the blog you might learn a few things.
> Colour me unimpressed.
I offered support to help fix already back in September. Of course I
also might be not able to fix the issue. Dagolden mentioned that the
biggest problem was 'lack of tuits' and any tuit would help, I think.
I actually did read the blog, and after I sent my email. You talk
about fixing it soon, which I really do hope. Don't get me wrong, I
absolutely appreciate your efforts, and I think it would be very
frustrating for you to deal with broken infrastructure, but reports
have been missing since before summer and the problems have grown from
bad to worse, in September I could see one in three reports I
submitted on the site, right now it is zero.
So, again, I really hope you can get this sorted. I just wanted to
share my growing lack of interest in running smokers, this was
mentioned by other people as well; all in all this is a risk for the
project.
On Mon, Nov 12, 2012 at 1:27 AM, Steffen Schwigon wrote:
> > Let's take as a sample case Test::Class. It have a meaningless test
> > fail, a patch waiting in the RT, and a lot of modules depending on it.
> > How can I find the list of modules that directly depend on it?
> > metacpan's reverse-dep give indirect deps too. I will file a bug to
> > all of them, and let's see what will happen.
> That's a great example, really. Because you already *have* the issue and
> patch available.
> Why would you inform all the dependent modules if the root cause is
> already known? From a single RT ticket which needs to be pushed you want
> to multiply that onto all affected modules?
because I'm trying to simulate an automated process, as Andreas Koenig
suggested.
There are people that are trying to fix CPAN manually, most notably (at
least recently) is Shlomi Fish. You can see his emails asking for comaint
popping up in the authors list.
I'm lazier then him, and seek systematic solution to systematic problem.
By that rationale a bug in a Perl core module would require a ticket in
> all 20_000 CPAN distros.
Fortunately, the Perl core is quite stable and well tested.
But the problem is not if there is some bug in the underlying software.
Bugs are OK. we can work around them. If my tests fails because of a bug in
some module, I will know about it, and can workaround it, or contact the
author of that module so he will fix it. or use other module. I can do
something about it.
But if it fails to install, I don't know about it. so I can't do anything
about it.
Shmuel Fomberg <shmuelfomb...@gmail.com> writes:
> On Mon, Nov 12, 2012 at 1:27 AM, Steffen Schwigon wrote:
>> Why would you inform all the dependent modules if the root cause is
>> already known? From a single RT ticket which needs to be pushed you
>> want to multiply that onto all affected modules?
> because I'm trying to simulate an automated process, as Andreas Koenig
> suggested. There are people that are trying to fix CPAN manually,
> most notably (at least recently) is Shlomi Fish. You can see his
> emails asking for comaint popping up in the authors list. I'm lazier
> then him, and seek systematic solution to systematic problem.
Ok, I generally understand your rationale, so even if I'm not convinced,
let's continue: how would you proceed after you have opened tickets on
all dependent modules?
On Mon, Nov 12, 2012 at 4:26 PM, Steffen Schwigon wrote:
> Shmuel Fomberg writes:
> > On Mon, Nov 12, 2012 at 1:27 AM, Steffen Schwigon wrote:
> >> Why would you inform all the dependent modules if the root cause is
> >> already known? From a single RT ticket which needs to be pushed you
> >> want to multiply that onto all affected modules?
> > because I'm trying to simulate an automated process, as Andreas Koenig
> > suggested. There are people that are trying to fix CPAN manually,
> > most notably (at least recently) is Shlomi Fish. You can see his
> > emails asking for comaint popping up in the authors list. I'm lazier
> > then him, and seek systematic solution to systematic problem.
> Ok, I generally understand your rationale, so even if I'm not convinced,
> let's continue: how would you proceed after you have opened tickets on
> all dependent modules?
I'm still thinking about what to write in the ticket itself, btw. I think
that a general ticket will be the best - "you are depending on a dep that
have a high failure rate, and so your module will probably won't install on
many of your clients. can you please stop using it?"
I don't say what I already know - on which systems it fails, that there is
ticket open with a patch. as I said - simulating a automated machine.
then I will track what happens. probable replies:
1. STFU. I don't care
2. I looked on the problem and it does not affect my module on my target
platforms. so, I don't care
3. Pinging Test::Class author, and getting him to fix it
4. Pinging T::C author, got a comaint and fixed it myself
5. ticket ignored
I want to show that by bugging the module authors that depend on a module,
maybe one of them will be motivated enough to fix it.
And I'm going only for the directly depending modules, as they are the most
likely to care, to be able to do something about it, and keeping the
'noise' to minimum.
Shmuel Fomberg <shmuelfomb...@gmail.com> writes:
>> Why would you inform all the dependent modules if the root cause is
>> already known? From a single RT ticket which needs to be pushed you want
>> to multiply that onto all affected modules?
> because I'm trying to simulate an automated process, as Andreas Koenig
> suggested.
Rereading my own mail I cannot recognizee that I suggested that.
On Tue, Nov 13, 2012 at 7:42 AM, Andreas Koenig wrote:
> Shmuel Fomberg writes:
> >> Why would you inform all the dependent modules if the root cause is
> >> already known? From a single RT ticket which needs to be pushed you want
> >> to multiply that onto all affected modules?
> > because I'm trying to simulate an automated process, as Andreas Koenig
> > suggested.
> Rereading my own mail I cannot recognizee that I suggested that.
Quoting:
Fill the bugtrackers and keep track of the tickets yourself, so we can
learn from the experience.
I may misunderstood your meaning, but sound to me like a good idea anyway...
Shmuel Fomberg <shmuelfomb...@gmail.com> writes:
> On Mon, Nov 12, 2012 at 4:26 PM, Steffen Schwigon wrote:
>> Shmuel Fomberg writes:
>> > On Mon, Nov 12, 2012 at 1:27 AM, Steffen Schwigon wrote:
>> >> Why would you inform all the dependent modules if the root cause is
>> >> already known? From a single RT ticket which needs to be pushed you
>> >> want to multiply that onto all affected modules?
>> > because I'm trying to simulate an automated process, as Andreas Koenig
>> > suggested. There are people that are trying to fix CPAN manually,
>> > most notably (at least recently) is Shlomi Fish. You can see his
>> > emails asking for comaint popping up in the authors list. I'm lazier
>> > then him, and seek systematic solution to systematic problem.
>> Ok, I generally understand your rationale, so even if I'm not convinced,
>> let's continue: how would you proceed after you have opened tickets on
>> all dependent modules?
> I'm still thinking about what to write in the ticket itself, btw. I
> think that a general ticket will be the best - "you are depending on a
> dep that have a high failure rate, and so your module will probably
> won't install on many of your clients. can you please stop using it?"
> I don't say what I already know - on which systems it fails, that
> there is ticket open with a patch. as I said - simulating a automated
> machine.
> then I will track what happens. probable replies:
> 1. STFU. I don't care
> 2. I looked on the problem and it does not affect my module on my target
> platforms. so, I don't care
> 3. Pinging Test::Class author, and getting him to fix it
> 4. Pinging T::C author, got a comaint and fixed it myself
> 5. ticket ignored
Hm, in IT this is called a Distributed Denial of Service attack.
You already have your use-case: Test::Class does not work for you. So
let's continue to analyze this single case:
- What did you already try to help the author?
- Why did your help not resolve the issue?
- What else can you do? Or,
what are your reasons you can not do more?
- What are the author's reasons he cannot solve the issue?
- Will more quantity solve the quality issue? Why will it?
Then scale up the thinking to all CPAN:
- What is the calculated criteria or barrier before auto-generating
tickets?
- Will every author have the same reasons for not solving issues, so
that there is indication the same approach will help the other
author's, too?
- Will this automation-approach scale-up to a huge bi-directionally
connected matrix of several thousand authors and users?
- How do you automatically track and close these multi-thousands of
automatically generated tickets?
On Tue, Nov 13, 2012 at 6:01 PM, Steffen Schwigon wrote:
> >> Ok, I generally understand your rationale, so even if I'm not convinced,
> >> let's continue: how would you proceed after you have opened tickets on
> >> all dependent modules?
> > then I will track what happens. probable replies:
> > 1. STFU. I don't care
> > 2. I looked on the problem and it does not affect my module on my target
> > platforms. so, I don't care
> > 3. Pinging Test::Class author, and getting him to fix it
> > 4. Pinging T::C author, got a comaint and fixed it myself
> > 5. ticket ignored
> Hm, in IT this is called a Distributed Denial of Service attack.
Distributed Request for Service? DRoS?
> You already have your use-case: Test::Class does not work for you. So
> let's continue to analyze this single case:
> - What did you already try to help the author?
A ticket was created, with a patch.
> - Why did your help not resolve the issue?
Ticket was ignored.
> - What else can you do? Or,
> what are your reasons you can not do more?
I can ask for comaint.
Sorry, won't do that anymore. I already took over two modules, and it is a
lot of hard work to learn and maintain somebody's else code.
I can contribute a patch, but no more.
> - What are the author's reasons he cannot solve the issue?
I don't know. the ticket was ignored.
> - Will more quantity solve the quality issue? Why will it?
Maybe an author will be motivated enough to push so it will be fixed?
Maybe Test::Class author will see that there are a lot of people that are
concerned about the his module failing to install that he will fix it
himself?
Then scale up the thinking to all CPAN:
> - What is the calculated criteria or barrier before auto-generating
> tickets?
If a module have test failures and was released more then a month ago, I
think that we can generate tickets.
> - Will every author have the same reasons for not solving issues, so
> that there is indication the same approach will help the other
> author's, too?
I don't understand the question.
> - Will this automation-approach scale-up to a huge bi-directionally
> connected matrix of several thousand authors and users?
> - How do you automatically track and close these multi-thousands of
> automatically generated tickets?
On Sun, Nov 11, 2012 at 11:07:36PM +0900, Shmuel Fomberg wrote:
> Let's take as a sample case Test::Class. It have a meaningless test fail, a
> patch waiting in the RT, and a lot of modules depending on it.
> How can I find the list of modules that directly depend on it?
Anyone who cannot cope with mathematics is not fully human.
At best he is a tolerable subhuman who has learned to wear
shoes, bathe and not make messes in the house.
-- Robert A Heinlein
Shmuel Fomberg <shmuelfomb...@gmail.com> writes:
> On Tue, Nov 13, 2012 at 7:42 AM, Andreas Koenig wrote:
> Shmuel Fomberg writes:
> >> Why would you inform all the dependent modules if the root cause is
> >> already known? From a single RT ticket which needs to be pushed you want
> >> to multiply that onto all affected modules?
> > because I'm trying to simulate an automated process, as Andreas Koenig
> > suggested.
> Rereading my own mail I cannot recognizee that I suggested that.
> Quoting:
> Fill the bugtrackers and keep track of the tickets yourself, so we can
> learn from the experience.
> I may misunderstood your meaning, but sound to me like a good idea anyway...
OK, I notice you have started and openened a couple of tickets
81189 Depending on Test::Class open Webservice-InterMine
81190 Depending on Test::Class new Net-ZooKeeper-Lock
81191 Depending on Test::Class open ParseUtil-Domain
81192 Depending on Test::Class new App-PM-Website
81193 Depending on Test::Class resolved Template-Plugin-Bootstrap-Pagination
81194 Depending on Test::Class new CHI
81195 Depending on Test::Class new WebService-Cmis
81196 Depending on Test::Class new Net-Thumper
81197 Depending on Test::Class new CHI-Driver-TokyoTyrant
And I find the same boilerplate text on all:
Hi. I notice that you module is depending on Test::Class. Test:Class
have a high test failure rate, and this means that a lot of the people
that want to install you module won't be able to. Worse, you can't even
see this failures in your CPAN testers reports, as dependency fail is
not reported. Can you please fix that? Thanks, Shmuel.
From my experience this text lacks a few more facts about what the
current state of the issue is. I think such a ticket should point to the
ticket in the bugtracker of Test::Class that reports the bug. It should
mention which release of Test::Class is affected and a link and/or text
that illustrates what "high failure rate" means in the concrete case.
All these informations help to track the whole story and improve the
chance that the tickets are useful for others.
In the concrete case
* I find several open tickets at rt.cpan.org and cannot recognize which
you are talking about.
* I find out there are four pull requests at
https://github.com/adrianh/test-class/pulls and cannot identify if any
of them has to do with your complaint. It would be interesting to know
whether one of those fixes the issue you are seeing.
The following last point I have is more a matter of taste: I would wish
that the sentence "Can you please fix that?" be dropped. Then the ticket
probably gets more of a chance to be taken as a help for others. But
feel free to ignore this last one, it's by far not so important as the
others.
> From my experience this text lacks a few more facts about what the
> current state of the issue is. I think such a ticket should point to the
> ticket in the bugtracker of Test::Class that reports the bug. It should
> mention which release of Test::Class is affected and a link and/or text
> that illustrates what "high failure rate" means in the concrete case.
> All these informations help to track the whole story and improve the
> chance that the tickets are useful for others.
It was done by purpose. I want to see how many authors will investigate,
and what they will do.
So I don't add any actual info on why these failures happened.
One author even asked "what do you want me to do?", and I replied that I'm
just providing a warning. what does he want to do?
It will just fail on non-*unix platform. mostly green indeed.
> The following last point I have is more a matter of taste: I would wish
> that the sentence "Can you please fix that?" be dropped. Then the ticket
> probably gets more of a chance to be taken as a help for others. But
> feel free to ignore this last one, it's by far not so important as the
> others.
A call for action is important. English is not my native language, and if
someone has better wording for it I'll use it.
Shmuel Fomberg <shmuelfomb...@gmail.com> writes:
> On Sun, Nov 18, 2012 at 6:15 PM, Andreas Koenig wrote:
> From my experience this text lacks a few more facts about what the
> current state of the issue is. I think such a ticket should point to the
> ticket in the bugtracker of Test::Class that reports the bug. It should
> mention which release of Test::Class is affected and a link and/or text
> that illustrates what "high failure rate" means in the concrete case.
> All these informations help to track the whole story and improve the
> chance that the tickets are useful for others.
> It was done by purpose. I want to see how many authors will investigate, and
> what they will do.
I believe this is a serious waste of developer resources. You're asking
23 people that they should do work. You withhold information you already
have or at least should have. You ask 23 people to do the same work like
all others, without letting them know that you're doing this in
parallel. This is not nice.
If it is a sociological study about the helpfulness of the cpan
population, you must make this clear in advance and you should ask the
wider community if they find carrying out studies of them acceptable.
But if you want to get things done, a bit more cooperativeness is called
for.
