On July 29, 2024 8:53:11 AM UTC, "Louis-Philippe Véronneau" <po...@debian.org> 
wrote:
>Hello,
>
>As discussed during the DebConf24 Python BoF, I'm submitting this change to 
>the policy to require the use of the upstream test suite, both during the 
>build process and as an autopkgtest.
>
>You can find the MR here:
>
>https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/24
>
>People present at the BoF seemed to think this was a good idea. If you don't 
>please reply to this message and make yourself heard :)

I understand the theory and why it's a good idea to run the test suite.  I 
don't think it ought to be a hard requirement.  I have several packages where 
there's a test suite, but I don't run it:

1.  The largest set is packages that need test only dependencies which are not 
packaged.  When I am packaging something new which has a test suite, then I 
generally package any needed test depends. If those test depends also need test 
depends packaged, I generally stop and don't enable tests for things that are 
only in the archives to support tests.  Noseofyeti is an example of this.

2.  There's at least one case where Debian has customizations that cause the 
test suite to fail, but the failures don't seem to cause any real problems.  If 
anyone wants to make it so the weasyprint test suite works on Debian, please 
knock yourself out.

3.  I also maintain multiple packages which require network access to run their 
test suite, so they can't run tests during build, only autopkgtests.

While I agree that running tests is good, it's not a universally reasonable 
requirement.

If we add this as a hard requirement for team packages, what do people think 
will happen?  Will people invest more volunteer time that they otherwise 
wouldn't have to add running tests?  Will they leave it for someone else on the 
team to address?  Will they remove packages from team maintenance?

Python policy is only enforceable within the team.  For the rest of the 
archive, it's a statement of best practices for people to consider.  Making 
this a hard requirement for team packages is a statement that we would rather 
such packages not be team maintained.  I don't think that's a good idea.

Scott K

Reply via email to