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? Kind regards, Steffen -- Steffen Schwigon <s...@renormalist.net> Perl benchmarks <http://perlformance.net> Dresden Perl Mongers <http://dresden-pm.org/>
