info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DPT repositories checks/"violations" report
0 views
Skip to first unread message
Sandro Tosi
Nov 27, 2021, 1:10:02 AM11/27/21
to
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
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
Scott Kitterman
Nov 27, 2021, 4:50:02 AM11/27/21
to
Scott K
Simon McVittie
Nov 27, 2021, 6:20:02 AM11/27/21
to
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
> 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.
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
Stefano Rivera
Nov 27, 2021, 9:00:02 AM11/27/21
to
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
> 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
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.
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
Louis-Philippe Véronneau
Nov 27, 2021, 1:20:03 PM11/27/21
to
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/
> 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 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.
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
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
Sandro Tosi
Dec 10, 2021, 1:40:03 AM12/10/21
to
> 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.
> 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.
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.
Sandro Tosi
Dec 12, 2021, 1:30:03 AM12/12/21
to
> 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:
> 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
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.
~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.
Louis-Philippe Véronneau
Jan 2, 2022, 8:00:05 PM1/2/22
to
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
>> 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
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 ;)
Scott Kitterman
Jan 3, 2022, 1:40:02 AM1/3/22
to
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
> 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 ;)
(modulo the one about using pypi, which I think we mostly agree isn't
something someone unfamiliar with the package can 'fix').
Scott K
Scott Kitterman
Jan 3, 2022, 3:20:03 PM1/3/22
to
On Monday, January 3, 2022 3:13:23 PM EST Louis-Philippe Véronneau wrote:
> 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
> 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
>
> > 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').
>
> 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
Louis-Philippe Véronneau
Jan 3, 2022, 3:20:03 PM1/3/22
to
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').
> (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.
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.
0 new messages