[arch-dev-public] namcap maintainership

[Kristian Klausen]

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