Front page | perl.perl5.porters |
Postings from February 2023
Regarding the thing about the automated CPAN testers infrastructure providing an automated "blead breaks cpan" report anyone can see, I feel that this idea has merit, and in theory it should be doable in a way that isn't too onerous. I take this as an extension of practices I see in some companies where there is an automated process that regularly runs the full build and test pipeline on trunk so its more clear if something broke as the result of a recent merge, often by devs not running all the tests etc before merging. What I suggest is that on a reasonably frequent but not too frequent schedule, such as once per 24 hours, each participating CPAN testers machine pulls the latest Perl blead, its trunk, and builds that, and then tries to build a selection of CPAN modules of its choice. I say "selection" under the assumption that a tester machine wouldn't do all of CPAN in one day, but if say it could normally get through all of CPAN in 5 days for an individual version of Perl, it would do 1/5 against one day's blead, the next 1/5 against the next day's blead, and so on round robin, so on the 6th day it does the first 1/5 again with a version of blead 5 days newer. In this scenario, the blead results are special, in that whenever a module is tested against blead "again", that result replaces the one from several days earlier, so that at any given time it isn't remembering more than one per module for blead, or blead is a rolling target. In this case, where one needs to know "when" blead broke CPAN, one can get enough granularity for this purpose in the CPAN testers testing of the monthly released dev versions. Mainly the interest is "does blead break this module NOW", and if it stops breaking then we're fine, and otherwise we compare that result to the most immediate dev version, and if it broke after that, we know it was as recent as since that release, and we have heads up that if the issue isn't addressed then the next dev release will also break the module, and possibly this can be prevented. Presumably part of the required logic changes to make this work is that the official Perl version in the report will need to say something like "blead" rather than whatever the most recently released normally numbered version is, since AFAIK trunk/blead continues to have that version formally until the next release is pumpkined, and I assume the normal CPAN testers logic simply uses the normally self-reported Perl version number. But the self-reported Perl version number would have to be left unchanged by this new logic so that any version-number-sensitive logic in any tests or modules doesn't have to know. So the end result is that the regular CPAN testers reports have an extra Perl pseudo-version that they report on called "blead" say but that rather than being a maybe-immutable log entry like normal test results, it regularly gets replaced any time the same module is tested against "blead" again, so it has a rolling meaning; if a module stops being tested then it just reflects the last time that module was tested. I realize this would take some work to setup, but hopefully not too much work, and I feel it could be very useful to the community and possibly cut down on some manual work to know if blead breaks cpan, while having a granularity of more than once a month. Although those doing the existing way can still keep doing that, especially if they want more immediate results than maybe once every few days or whatever. -- Darren DuncanThread Previous | Thread Next