> On Oct 20, 2017, at 10:42 AM, Todd Rinaldo <to...@cpanel.net> wrote: > >> On Oct 17, 2017, at 1:06 PM, Doug Bell <d...@preaction.me> wrote: >> >> >>> On Oct 14, 2017, at 8:34 AM, James E Keenan <jkee...@pobox.com> wrote: >>> >>> Would it be possible to generate a monthly report from data in the >>> CPANtesters database(s), identifying all CPAN libraries: >>> >>> (i) which had not had a new version uploaded to CPAN in the past month; but >>> >>> (ii) which had experienced new breakage in their test suites in the past >>> month -- breakage which could hypothetically be attributed to a change in >>> the Perl 5 source code from one monthly development release to the next? >>> >>> I realize that that question is probably not yet precise enough to be >>> translated into a database query. However, we welcome your insights into >>> how CPANtesters data can be leveraged for the benefit of better Perl 5 core >>> development. >> >> It seems like what you want is: >> >> 1) All the CPAN distributions that have not had a new release in 1 month >> 2) AND have at least 1 PASS report against the latest stable Perl release >> 3) AND have at least 1 report against the latest dev Perl release >> 4) AND have 0 PASS reports against the latest dev Perl release >> >> CPAN Testers can do _almost_ all of that right now using the data we have, >> except for "What is the latest stable Perl release?" and "What is the latest >> dev Perl release?" Adding that data dovetails nicely with the existing >> problem of the Perl version list on CPAN Testers is out of date. > > Doug, > > Thanks for the reply. I proposed this idea originally. Essentially the > thought was to use the data already there to hint to p5p there might be a > problem worth digging into. The alternative would be to build Yet Another > Smoking System. In accordance with the 3 great virtues, I'm way too lazy for > that. > > What needs doing to make this a "report" of sorts that could be dug through > by interested parties? Are we just talking about a flat file that a perl > release manager could update which would provide this information to whoever?
I was thinking a web page on beta.cpantesters.org <http://beta.cpantesters.org/> to run the query. It's almost a single SQL query to get the data. The work would be: 1) Write a new process to write the perl_versions table. This process should read the CPAN mirror and write which versions of Perl exist, whether they are stable/devel. This is a replacement for a process that has been replaced (except for this functionality). This would be a new module in http://github.com/cpan-testers/cpantesters-backend <http://github.com/cpan-testers/cpantesters-backend> and require adding a PerlVersions DBIx::Class module to http://github.com/cpan-testers/cpantesters-schema <http://github.com/cpan-testers/cpantesters-schema>. 2) Add date/time data to the perl_versions table. Each Perl release needs to be accompanied by the date/time of its release to determine which is "latest". This requires adding the right columns to the schema and making sure they're inserted/updated by the process in (1). This must be done as a second release to ensure that the DBIx::Class schema versioning does the upgrade correctly. 3) Develop a PerlSmoke controller for a web page which runs the above query and displays the list of possible problems. This is adding a CPAN::Testers::Web::Controller::PerlSmoke module to http://github.com/cpan-testers/cpantesters-web <http://github.com/cpan-testers/cpantesters-web> and an associated template to render the data (with some UI work to make it easy to read). If anybody wants to do that, I can help guide them as they go. I imagine there could be some useful interactivity to add to this page: Attaching bug reports, adding comments, marking resolved, etc... But these 3 things should be the minimum useful product. If it turns out the query takes too long, we can add a backend process that updates a report table. This would be most useful if organized by Perl development version and date/time (so we could see which problems got resolved and which problems have remained for which versions). Even if we don't need it for performance, this could also be a future enhancement to automate more of the process.
signature.asc
Description: Message signed with OpenPGP
