Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #13730 > unrolled thread

DPT repositories checks/"violations" report

Back to article view | Back to linux.debian.maint.python

Contents

  DPT repositories checks/"violations" report Sandro Tosi <morph@debian.org> - 2021-11-27 07:10 +0100
    Re: DPT repositories checks/"violations" report Scott Kitterman <debian@kitterman.com> - 2021-11-27 10:50 +0100
      Re: DPT repositories checks/"violations" report Simon McVittie <smcv@debian.org> - 2021-11-27 12:20 +0100
    Re: DPT repositories checks/"violations" report Stefano Rivera <stefanor@debian.org> - 2021-11-27 15:00 +0100
      Re: DPT repositories checks/"violations" report Louis-Philippe Véronneau <pollo@debian.org> - 2021-11-27 19:20 +0100
      Re: DPT repositories checks/"violations" report Sandro Tosi <morph@debian.org> - 2021-12-10 07:40 +0100
        Re: DPT repositories checks/"violations" report Sandro Tosi <morph@debian.org> - 2021-12-12 07:30 +0100
          Re: DPT repositories checks/"violations" report Louis-Philippe Véronneau <pollo@debian.org> - 2022-01-03 02:00 +0100
            Re: DPT repositories checks/"violations" report Scott Kitterman <debian@kitterman.com> - 2022-01-03 07:40 +0100
              Re: DPT repositories checks/"violations" report Scott Kitterman <debian@kitterman.com> - 2022-01-03 21:20 +0100
              Re: DPT repositories checks/"violations" report Louis-Philippe Véronneau <pollo@debian.org> - 2022-01-03 21:20 +0100

#13730 — DPT repositories checks/"violations" report

Hello,
while working on something else[1], i noticed how many of the
repositories in the DPT salsa group are in poor shape:

* missing branches
* changes not pushed to salsa
* general misalignment in configuration/setup/organization
* many other small nuances

[1] https://github.com/sandrotosi/debian-python-team-tracker

That makes it hard to make mass work as in [1], so I thought it would
be interesting to have a tool to evaluate the amount of issues our
repos have, and identify such "violations" so that they can be
addressed.

That information is now available at [2].

[2] https://github.com/sandrotosi/dpt-repos-check/blob/main/violations.txt

please take the content with caution, as it's still an early, raw
draft (i spot-checked some of the reported issues, but there could be
bugs/issues) and it contains data that can be outdated (see below re
caching); the fact that the report indicates only 43 repos are without
violations is a bit disarming, but i think the tool tries to err on
the side of verbosity and pedantry, with 2 level of violations (ERROR
and WARNING) to mark which ones are the most important that require
immediate attention vs the nice-to-have ones.

The checks are under-documented, although they should be somehow
self-explanatory. While the current format is just a text file, I plan
on getting it converted to markdown, although I'm still not sure how
to convey that amount of information effectively.

The report is extremely intensive to generate, as it needs to make 10+
API calls to salsa.d.o for each repository, and it gets throttled
quite early in the run (i got away in dev by installing a cache, so
that i could test it without hitting salsa every time, but that makes
some info stale); for that reason, and if we decide is valuable to
generate it periodically, i don't expect to be able to run it more
than once a month (maybe once a week? TBD).

Comments, critics and improvements are welcome.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [next] | [standalone]

#13731

On November 27, 2021 6:01:08 AM UTC, Sandro Tosi <morph@debian.org> wrote:
>Hello,
>while working on something else[1], i noticed how many of the
>repositories in the DPT salsa group are in poor shape:
>
>* missing branches
>* changes not pushed to salsa
>* general misalignment in configuration/setup/organization
>* many other small nuances
>
>[1] https://github.com/sandrotosi/debian-python-team-tracker
>
>That makes it hard to make mass work as in [1], so I thought it would
>be interesting to have a tool to evaluate the amount of issues our
>repos have, and identify such "violations" so that they can be
>addressed.
>
>That information is now available at [2].
>
>[2] https://github.com/sandrotosi/dpt-repos-check/blob/main/violations.txt
>
>please take the content with caution, as it's still an early, raw
>draft (i spot-checked some of the reported issues, but there could be
>bugs/issues) and it contains data that can be outdated (see below re
>caching); the fact that the report indicates only 43 repos are without
>violations is a bit disarming, but i think the tool tries to err on
>the side of verbosity and pedantry, with 2 level of violations (ERROR
>and WARNING) to mark which ones are the most important that require
>immediate attention vs the nice-to-have ones.
>
>The checks are under-documented, although they should be somehow
>self-explanatory. While the current format is just a text file, I plan
>on getting it converted to markdown, although I'm still not sure how
>to convey that amount of information effectively.
>
>The report is extremely intensive to generate, as it needs to make 10+
>API calls to salsa.d.o for each repository, and it gets throttled
>quite early in the run (i got away in dev by installing a cache, so
>that i could test it without hitting salsa every time, but that makes
>some info stale); for that reason, and if we decide is valuable to
>generate it periodically, i don't expect to be able to run it more
>than once a month (maybe once a week? TBD).
>
>Comments, critics and improvements are welcome.

I don't think the pypi tarball "issue" should be presumed to be a problem at all.  I wasn't paying attention to Debian when that discussion happened, but in my experience there was a lot wrong with the idea.  A properly constructed sdist is exactly what we want to build a package from.  That's almost never found on GitHub.

Scott K

[toc] | [prev] | [next] | [standalone]

#13733

On Sat, 27 Nov 2021 at 09:38:41 +0000, Scott Kitterman wrote:
> I don't think the pypi tarball "issue" should be presumed to be a
> problem at all.  I wasn't paying attention to Debian when that discussion
> happened, but in my experience there was a lot wrong with the idea.
> A properly constructed sdist is exactly what we want to build a package
> from.  That's almost never found on GitHub.

I think the closest we got to a conclusion was "it depends": if your
upstream reliably produces a properly constructed sdist (or at least is
happy to accept pull requests to make their sdist properly constructed)
then it makes an ideal source package, but if your upstream treats sdists
in closer to the same way a C programmer would treat a prebuilt binary
release (omitting source and including content generated from that source
instead), then a git clone is probably more appropriate.

To me, at least, it makes sense for this to be a case-by-case decision
made by someone who is familiar with this specific upstream - and wanting
to have someone familiar with this specific upstream is why we have named
maintainers, rather than having everything collectively-maintained like
some distributions do.

(For what it's worth, the GNOME team uses a mixture of `meson dist` and
git clones, and that's with an upstream that is a single project that is
in principle meant to be team-maintained with a single cohesive policy -
so if we can't standardize on one source format being "always the right
one" for GNOME, I would be very surprised if the Python team was able to
standardize on one source format for a large number of separate upstreams
linked only by their implementation language.)

    smcv

[toc] | [prev] | [next] | [standalone]

#13735

Hi Sandro (2021.11.27_06:01:08_+0000)

> Hello,
> while working on something else[1], i noticed how many of the
> repositories in the DPT salsa group are in poor shape:
> 
> * missing branches
> * changes not pushed to salsa
> * general misalignment in configuration/setup/organization
> * many other small nuances
> 
> [1] https://github.com/sandrotosi/debian-python-team-tracker

+1 this is great!

I've been doing some 3.10 NMUs recently, and found myself re-creating
several upstream and pristine-tar branches...

> please take the content with caution, as it's still an early, raw
> draft (i spot-checked some of the reported issues, but there could be
> bugs/issues) and it contains data that can be outdated (see below re
> caching); the fact that the report indicates only 43 repos are without
> violations is a bit disarming, but i think the tool tries to err on
> the side of verbosity and pedantry, with 2 level of violations (ERROR
> and WARNING) to mark which ones are the most important that require
> immediate attention vs the nice-to-have ones.

When we did the migration to git, there weren't good tools for managing
the setup of the salsa repos (hooks, etc.) yet.  I'd assume those exist
now, we should check in with what other teams are doing. That stuff can
all be fixed in one run of a tool, I'd assume.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

#13736

[Multipart message — attachments visible in raw view] — view raw

On 2021-11-27 08 h 54, Stefano Rivera wrote:
> Hi Sandro (2021.11.27_06:01:08_+0000)
> 
>> Hello,
>> while working on something else[1], i noticed how many of the
>> repositories in the DPT salsa group are in poor shape:
>>
>> * missing branches
>> * changes not pushed to salsa
>> * general misalignment in configuration/setup/organization
>> * many other small nuances
>>
>> [1] https://github.com/sandrotosi/debian-python-team-tracker
> 
> +1 this is great!

\0/

I've been wanting something for QA like that for a while, but never had
the time / energy to look into it further. All in all, it's too easy to
forget to push something to Salsa and never realise it.

>> please take the content with caution, as it's still an early, raw
>> draft (i spot-checked some of the reported issues, but there could be
>> bugs/issues) and it contains data that can be outdated (see below re
>> caching); the fact that the report indicates only 43 repos are without
>> violations is a bit disarming, but i think the tool tries to err on
>> the side of verbosity and pedantry, with 2 level of violations (ERROR
>> and WARNING) to mark which ones are the most important that require
>> immediate attention vs the nice-to-have ones.
> 
> When we did the migration to git, there weren't good tools for managing
> the setup of the salsa repos (hooks, etc.) yet.  I'd assume those exist
> now, we should check in with what other teams are doing. That stuff can
> all be fixed in one run of a tool, I'd assume.

Could this become part of the Debian Janitor at some point?

I could see teams adding a per-team config file to check things like
what branch names should be expected, etc. and the Janitor fixing all
this if it has commit access.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
  ⠈⠳⣄

[toc] | [prev] | [next] | [standalone]

#13772

> When we did the migration to git, there weren't good tools for managing
> the setup of the salsa repos (hooks, etc.) yet.  I'd assume those exist
> now, we should check in with what other teams are doing. That stuff can
> all be fixed in one run of a tool, I'd assume.

yeah i figured that much, and that made sense at that time.

I modified [1] to automatically create the salsa repo enabling both
KGB and tagpending webhooks, but the `salsa` tool doesnt support
setting integrations, so that will need to be fixed later on.

[1] https://github.com/sandrotosi/pypi2deb/tree/morph

I'm in the process of writing a tool to uniform the repo configuration
in python-team/package

- add integration: Emails on push
- remove integration Irker
- add webhook: KGB (or edit to remove all the extra parameters set,
which are the default values anyway)
- add webhook: tagpending

I'll write back here when i think it's ready for review and request
authorization to run it.

I think there's still one point we need to figure out: how to make
these remarks known to the packages maintainers, instead of all of
them just being in a text file.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [next] | [standalone]

#13776

> I'm in the process of writing a tool to uniform the repo configuration
> in python-team/package
>
> - add integration: Emails on push
> - remove integration Irker
> - add webhook: KGB (or edit to remove all the extra parameters set,
> which are the default values anyway)
> - add webhook: tagpending

the tool is now ready:
https://github.com/sandrotosi/dpt-repos-check/blob/main/dpt-fix-integrations-webhooks.py

> I'll write back here when i think it's ready for review and request
> authorization to run it.

can any admin check if the changes look sane (i've run a test run on
~25 repos) and that i'm allowed to run this across the whole
`packages` subgroup on salsa?

> I think there's still one point we need to figure out: how to make
> these remarks known to the packages maintainers, instead of all of
> them just being in a text file.

This is still an open point, and i welcome ideas

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [next] | [standalone]

#13845

[Multipart message — attachments visible in raw view] — view raw

On 2021-12-12 01 h 23, Sandro Tosi wrote:
>> I think there's still one point we need to figure out: how to make
>> these remarks known to the packages maintainers, instead of all of
>> them just being in a text file.
> 
> This is still an open point, and i welcome ideas

Is there a reason why we shouldn't just file bugs in the BTS? I get it's
not the perfect tool for that, but it would certainly help reach the
maintainers.

Using a common usertag would also make it easier to find and fix these
issues en masse ;)

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
  ⠈⠳⣄

[toc] | [prev] | [next] | [standalone]

#13847

[Multipart message — attachments visible in raw view] — view raw

On Sunday, January 2, 2022 7:50:02 PM EST Louis-Philippe Véronneau wrote:
> On 2021-12-12 01 h 23, Sandro Tosi wrote:
> 
> >> I think there's still one point we need to figure out: how to make
> >> these remarks known to the packages maintainers, instead of all of
> >> them just being in a text file.
> > 
> > 
> > This is still an open point, and i welcome ideas
> 
> 
> Is there a reason why we shouldn't just file bugs in the BTS? I get it's
> not the perfect tool for that, but it would certainly help reach the
> maintainers.
> 
> Using a common usertag would also make it easier to find and fix these
> issues en masse ;)

Since this is all about team Git repositories, someone should just fix them 
(modulo the one about using pypi, which I think we mostly agree isn't 
something someone unfamiliar with the package can 'fix').

Scott K

[toc] | [prev] | [next] | [standalone]

#13854

[Multipart message — attachments visible in raw view] — view raw

On Monday, January 3, 2022 3:13:23 PM EST Louis-Philippe Véronneau wrote:
> On 2022-01-03 01 h 30, Scott Kitterman wrote:
> 
> > Since this is all about team Git repositories, someone should just fix
> > them 
 (modulo the one about using pypi, which I think we mostly agree
> > isn't something someone unfamiliar with the package can 'fix').
> 
> But that doesn't prevent future errors from popping up and doesn't make
> maintainers aware of their errors (so they can learn from it).
> 
> I think the "perfect" solution would be to have an automated tool (aka
> janitor) fixing these automatically, but this would require more work.

The first step if we think these things should be the standard for team 
repositories is to document it.  Personally, I would look here:

https://wiki.debian.org/Python/GitPackaging#Creating_new_repositories

At least for me, a good explanation of what to do in the documentation would 
be much more valuable than a bug report.  Approximately all  of the team 
repositories I've created are "wrong" because I followed the documentation.

Scott K

[toc] | [prev] | [next] | [standalone]

#13855

[Multipart message — attachments visible in raw view] — view raw

On 2022-01-03 01 h 30, Scott Kitterman wrote:
> Since this is all about team Git repositories, someone should just fix them 
> (modulo the one about using pypi, which I think we mostly agree isn't 
> something someone unfamiliar with the package can 'fix').
But that doesn't prevent future errors from popping up and doesn't make
maintainers aware of their errors (so they can learn from it).

I think the "perfect" solution would be to have an automated tool (aka
janitor) fixing these automatically, but this would require more work.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
  ⠈⠳⣄

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web