How to make raku-* module packages migrate faster [was: Re: raku-hash-merge]

[Timo Paulssen]

I asked further on the #debian-mentors channel and got this advice:

20:08 <wRAR> timo1: in Python packages we usually just run the upstream 
test suite against the installed module
20:08 <Sebastinas> FWIW, packages currently do not get a bounty even if 
the have successful autopkgtests
20:09 <wRAR> indeed.
20:09 <timo1> do the packages also run the test suite while building the 
debian package?
20:10 <wRAR> the Python ones? of course, unless that's not feasible 
which is very rare

So we could indeed use the existing test suites from module packages as 
autopkgtests.

20:26 <wRAR> either write debian/tests/control manually or use autodep8 
to generate one
20:26 <wRAR> by adding support for raku to it, preferably
20:27 <timo1> ok, so a source contribution to autodep8 would likely be 
the best way
20:29 <wRAR> "replacing `dh_auto_test` with `dh_raku_test`" sounds wrong 
though, you should make dh_auto_test run your tests, via 
/usr/share/perl5/Debian/Debhelper/Buildsystem/raku.pm

So at least in the long term we should maybe contribute dh-raku's 
functionality to debhelper upstream to become 
lib/Debian/Debhelper/Buildsystem/raku.pm.

For now, as we are still figuring stuff out and we may flop back to 
packaging precompilation files, I would assume keeping dh-raku under 
"our own control" would be preferable.

And in terms of autopkgtests for raku modules, we should contribute 
something to the autodep8 tool.

Does that sound good?
   - Timo

On 5/12/25 22:06, Timo Paulssen wrote:
> AFAICT we can only reduce the time by adding autopkgtests to our 
> package as well as the reverse dependencies, but there is also the 
> possibility of an "unblock request" to the release team, which I 
> assume is for when we make an upload after the hard freeze and the 
> package would not be able to migrate to testing at all unless we get 
> an exception made.
>
> This was just discussed on #debian-maintainers recently, and last time 
> I asked about the 10 days, which was on the 5th of may, IRC user wRAR 
> told me "there is no way to get it migrate faster than 10 days".
>
> I would of course be happy to hear of a way to get faster migrations 
> anyway.
>
> I wonder if it makes sense to have the tests from the modules both for 
> when we build the packages, and for autopkgtest, but AIUI autopkgtest 
> is more about "integration testing" with the whole system, whereas the 
> tests in the module are usually a lot more like "unit tests".
>
> https://wiki.debian.org/ContinuousIntegration/AutopkgtestBestPractices 
> has this to say:
>
>>
>>   Recommendations
>>
>>   * Use upstream test-suite if they have as-installed test
>>
>
> But I think "as-installed" is not what the tests we have in the 
> modules actually refers to, and I'm not entirely sure we can come up 
> with tests for all our modules, at least not very quickly :)
>
> HTH
>   - Timo
>
>
> On 5/11/25 19:18, Dominique Dumont wrote:
>> On Friday, 9 May 2025 11:51:22 Central European Summer Time Santiago 
>> Vila
>> wrote:
>>> It might be worth
>>> to contact Release Managers so that the time required for that is 
>>> reduced
>>> a little bit from the default 10 days.
>> Do you know how to do this ?
>>
>> All the best
>>
>>
>>
>>
>> _______________________________________________
>> Pkg-rakudo-devel mailing list
>> Pkg-rakudo-devel at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rakudo-devel 
>>
>