[arch-dev-public] namcap maintainership
Hi All, I find a bit unfortunate to write this email, but I've emailed keenerd one month ago about git.archlinux.org being deprecated and namcap which he maintains being moved to Gitlab. So far I have not received a reply from keenerd. It also seems that namcap has not seen commits in a year and there are patches on the mailing list (arch-projects) for it. [2] [3] I would love to see someone from our team pick up namcap maintainership, take a look at all the pending patches, bugs on the tracker and keep it in shape. Is anyone interested in potentially picking up this task? [1] https://gitlab.archlinux.org/pacman/namcap [2] https://lists.archlinux.org/pipermail/arch-projects/2021-January/005411.html [3] https://lists.archlinux.org/pipermail/arch-projects/2020-December/005403.htm... Kind regards, Jelle van der Waa
On 2021-08-21 22:24, Jelle van der Waa via arch-dev-public wrote:
I would love to see someone from our team pick up namcap maintainership, take a look at all the pending patches, bugs on the tracker and keep it in shape. Is anyone interested in potentially picking up this task?
I may be interested. Actually I'm quite interested but have a couple hesitations: * Python isn't my favorite or strongest suit. I can get around in it of course, and for maintenance work and facilitating other contributions I think it would suffice. * I'm close to maxed out on time commitments and don't want to say I'll do more than I'll actually get around to doing. I can at least help transition it from "abandoned" to "maintained" mode. I probably can't spearhead an effort to overhaul it or take it in bold new directions, but I don't necessarily think that's what it needs either. If fending off bitrot and facilitating other contributors is what it needs, I'm willing to jump in. It would be nice if at least one or two others were interested in joining that effort in tandem though. Caleb
On Sat, 2021-08-21 at 22:41 +0300, Caleb Maclennan via arch-dev-public wrote:
On 2021-08-21 22:24, Jelle van der Waa via arch-dev-public wrote:
I would love to see someone from our team pick up namcap maintainership, take a look at all the pending patches, bugs on the tracker and keep it in shape. Is anyone interested in potentially picking up this task?
I may be interested. Actually I'm quite interested but have a couple hesitations:
* Python isn't my favorite or strongest suit. I can get around in it of course, and for maintenance work and facilitating other contributions I think it would suffice.
* I'm close to maxed out on time commitments and don't want to say I'll do more than I'll actually get around to doing. I can at least help transition it from "abandoned" to "maintained" mode. I probably can't spearhead an effort to overhaul it or take it in bold new directions, but I don't necessarily think that's what it needs either.
If fending off bitrot and facilitating other contributors is what it needs, I'm willing to jump in. It would be nice if at least one or two others were interested in joining that effort in tandem though.
Caleb
I am also interested and can drive the Python side of discussions/reviews. I am definitely also interested in the technical side of changes, but if someone can commit to co-maintaining with me focusing more on that side, it would be optimal. Similarly, I am also have a bottleneck on time commitments, but that mostly affects development or reviewing large changes. I work remotely, so I basically spend all day in front of the computer, which means I should be fairly responsive for things that don't require me to take a big chunk of my time aside. Cheers, Filipe Laíns
On August 21, 2021 9:24:20 PM GMT+02:00, Jelle van der Waa via arch-dev-public <arch-dev-public@lists.archlinux.org> wrote:
I would love to see someone from our team pick up namcap maintainership, take a look at all the pending patches, bugs on the tracker and keep it in shape. Is anyone interested in potentially picking up this task?
[1] https://gitlab.archlinux.org/pacman/namcap [2] https://lists.archlinux.org/pipermail/arch-projects/2021-January/005411.html [3] https://lists.archlinux.org/pipermail/arch-projects/2020-December/005403.htm...
As Python is sort of my daily bread-and-butter at work these days, I can certainly help with getting things back in shape, setting up some form of automation, etc. Having the project on our gitlab already simplifies things quite a bit. Due to huge time commits on other tooling in our infrastructure I would not be able to actively maintain it though and I'd be happy to see e.g. Filipe and/or Caleb work that out :) Best, David P.S.: Sorry, on phone and can't sign this mail. -- https://sleepmap.de
On 22/08/2021 10:10, David Runge via arch-dev-public wrote:
On August 21, 2021 9:24:20 PM GMT+02:00, Jelle van der Waa via arch-dev-public <arch-dev-public@lists.archlinux.org> wrote:
I would love to see someone from our team pick up namcap maintainership, take a look at all the pending patches, bugs on the tracker and keep it in shape. Is anyone interested in potentially picking up this task?
[1] https://gitlab.archlinux.org/pacman/namcap [2] https://lists.archlinux.org/pipermail/arch-projects/2021-January/005411.html [3] https://lists.archlinux.org/pipermail/arch-projects/2020-December/005403.htm...
A bit late to the party, but definitely a Python guy and interested in co-maintainership. Count me in. -- Regards, Konstantin
On 2021-08-21 22:24, Jelle van der Waa via arch-dev-public wrote:
I would love to see someone from our team pick up namcap maintainership, [...]
Is there any progress on this decision? So far we have 4 of us that are interested in maintaining and/or contributing to the project. But, as I understand it, until somebody (?) makes an executive decision and we get some permissions on the project repo there is only so much any of us can do. I'm happy to work with any/all of Filipe, David, or Konstantin. I would suggest a relatively flexible workflow where one of us (whoever is going to manage delegating permissions and pull the trigger on releases) at least has maintainer accesses to the current repository on GitLab, and all the other parties that have volunteered to date (and possibly future ones) are given developer level permissions. Then we can setup the master branch protections such that 1 approval is required for merge requests. Any one of us could handle 3rd party contributions, and we can ourselves contribute with any one other party signing off on reviews. That way there isn't a huge bottleneck on one the development process if/when people are motivated to contribute. Only possibly the release tagging would be a single contact point (the maintainer). I've scrubbed through the mailing list and found all the patches that have come in since the last commit to the repo and opened issues to review each of them. If this is going to move forward I can also collect said patches into MRs that can be reviewed from GitLab and possible scrounge up the existing feedback they got on the projects list. Dealing with those past contributions will at least be a first step. With a little motion on the project and a pathway for contributions to actually be processed I'm hopeful more devs/TUs will chip in over time — given this is something we are all exposed to. Caleb
On 28.08.2021 17.37, Caleb Maclennan via arch-dev-public wrote:
On 2021-08-21 22:24, Jelle van der Waa via arch-dev-public wrote:
I would love to see someone from our team pick up namcap maintainership, [...]
Is there any progress on this decision? So far we have 4 of us that are interested in maintaining and/or contributing to the project. But, as I understand it, until somebody (?) makes an executive decision and we get some permissions on the project repo there is only so much any of us can do.
I'm happy to work with any/all of Filipe, David, or Konstantin. I would suggest a relatively flexible workflow where one of us (whoever is going to manage delegating permissions and pull the trigger on releases) at least has maintainer accesses to the current repository on GitLab, and all the other parties that have volunteered to date (and possibly future ones) are given developer level permissions. Then we can setup the master branch protections such that 1 approval is required for merge requests. Any one of us could handle 3rd party contributions, and we can ourselves contribute with any one other party signing off on reviews. That way there isn't a huge bottleneck on one the development process if/when people are motivated to contribute. Only possibly the release tagging would be a single contact point (the maintainer).
I added you all as developer and added a approval rule requiring one of you to approve every merge request. So coordinate and start hacking :) Please ping me or another from the DevOps team if you need more tweaking or perhaps we can make one of you a maintainer. Kristian
I've scrubbed through the mailing list and found all the patches that have come in since the last commit to the repo and opened issues to review each of them. If this is going to move forward I can also collect said patches into MRs that can be reviewed from GitLab and possible scrounge up the existing feedback they got on the projects list. Dealing with those past contributions will at least be a first step. With a little motion on the project and a pathway for contributions to actually be processed I'm hopeful more devs/TUs will chip in over time — given this is something we are all exposed to.
Caleb
participants (6)
-
Caleb Maclennan
-
David Runge
-
Filipe Laíns
-
Jelle van der Waa
-
Konstantin Gizdov
-
Kristian Klausen