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.
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
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.
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!
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.
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'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.
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 ;)
On 2022-01-03 01 h 30, Scott Kitterman wrote:(modulo the one about using pypi, which I think we mostly agree
Since this is all about team Git repositories, someone should just fix
them
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 349 |
Nodes: | 16 (2 / 14) |
Uptime: | 117:26:26 |
Calls: | 7,612 |
Files: | 12,786 |
Messages: | 5,683,872 |