On 10/20/2017 12:21 PM, Doug Bell wrote:
On Oct 20, 2017, at 10:42 AM, Todd Rinaldo <to...@cpanel.net
<mailto:to...@cpanel.net>> wrote:
On Oct 17, 2017, at 1:06 PM, Doug Bell <d...@preaction.me
<mailto:d...@preaction.me>> wrote:
On Oct 14, 2017, at 8:34 AM, James E Keenan <jkee...@pobox.com
<mailto: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 and require
adding a PerlVersions DBIx::Class module to
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 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.
Sounds like (the beginning of) a plan!
jimk
