develooper Front page | perl.perl5.porters | Postings from February 2023

Re: Deprecation doesn't mean we have two release cycles beforethings break.

Thread Previous | Thread Next
Darren Duncan
February 28, 2023 11:56
Re: Deprecation doesn't mean we have two release cycles beforethings break.
Message ID:
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 Duncan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About