search

openwrt / packages

Community maintained packages for OpenWrt. Documentation for submitting pull requests is in CONTRIBUTING.md
GNU General Public License v2.0
3.94k stars 3.45k forks source link

meta: commit access for new contributors #15257

Open aparcar opened 3 years ago

aparcar commented 3 years ago

Hello @openwrt/package-maintainers

I get every other week a request to give some active contributor commit access to packages.git.

What is our strategy for that? Personal intuition seems a bit vague.

As suggested some time ago I'd like to have a CODEOWNERS file which limits peoples access within the repository, at least notifying the specific maintainer if someone touches their maintained package.

A possible solution from my view is to give fresh maintainers commit access after 5 formally correct and sane PRs but limit their access to the one specific package they're maintaining. If things go well they can be added to the @openwrt/package-maintainers group and get "full" access, including adding new packages or reviewing other peoples PRs.

Opinions?

aparcar commented 3 years ago

Ping @champtar @hnyman @neheb @jefferyto @BKPepe

pprindeville commented 3 years ago

Works for me.

BKPepe commented 3 years ago

I am not saying that there should be some strict policy, but we need to be careful.

In my opinion, I am not sure how do we define "active contributor" in this repository, and I would be glad if the rules would be applied to everyone. Let's start with some statistics before I got to my point.

Why these guys do not have commit access?

To be fair, two years ago (https://github.com/openwrt/packages/issues/8469), I asked for the same, but I sent closely to 40 PRs and a few reviews. So, we have something to compare. Even though I have commit access, I am still sending PRs because it has advantages as CI/CD compiles it for multiple platforms and tries to run tested on some. Others can review it before merging it.

At that time, I thought it is hard to get there, and I need to earn it or deserve it. Someone will notice that I am sending PRs, and they start voting like it was done in the past or like it is done nowadays for the main repository. We should have something like it, though. Because recently, more people got their commit access, and I can not see them much.

I don't want to offend anyone, but I don't think that someone should get commit access because he/she knows him/her or even he/she added himself/herself recently to be maintainer or co-maintainer of the package. From my perspective, the maintainer stated in Makefile can be without commit access as he should take care of that package if they are issues or update it regularly like @jefferyto and @commodo are doing it here for a long time. Thank you guys.

For some time, I believe that there is a lack of maintainers, and that's true. Currently, @neheb is the most active maintainer, and I need to thank him for his work! How many people are reviewing pull requests or joining the discussion in meta-issues? :thinking:

How long will @neheb do that? That's a good question, and I am not sure if I have an answer for that. Definitely, we need more people, but with commit access comes responsibility and presentation.

diizzyy commented 3 years ago

I can honestly say that I'm not very active due to various reasons but the little time I have I usually spend on other things these days so my opinion might not worth much but here goes...

The constant indecisiveness and lack of communication within the project hurts more than it helps in terms of being "free" (to do whatever you want). Giving people access because they maintain perhaps 2-3 packages is not really an argument especially if they don't engage in reviewing other PRs/packages and try to keep things consistent (which is more or less impossible in practice because there's no documentation). I really tried to keep things rolling in this direction but with little to no engagement I stopped caring. If you want to implement something like this, who is willing and going to maintain it? A single person is a no go for obvious reasons. No other repo to my knowledge uses this approach simply because it takes more time and effort than it's worth and as @BKPepe pointed out it also entails responsibility.

neheb commented 3 years ago

@BKPepe not too long. I think after dealing with https://github.com/openwrt/packages/pull/15012 my contributions will go down.

commodo commented 3 years ago

Why these guys do not have commit access?

  • @commodo (co-maintainer of Python as well, sent more than 385 PRs | FACT:: PRs to this repository since 2014, though tada )

i was offered commit access to this repo a few times, i think dating back since 2014-2015 [since i started maintaining Python 2 & 3] but i refused it :) i am not sure about @jefferyto , but i think he also got offered a few times;

reason i refused it at the time, is because i did not want to commit too much time/energy here; and i am still happy with the amount of time/energy i need to allocate on this repo;

the only reason i would want commit access is to help out; otherwise the current system [with no commit rights] works for me; i cannot guarantee i will do more than i am already doing though :)

so, if you want to give me commit access, i humbly accept it [this time]; i also reserve the right to withdraw back [at any time] to my current mode [i.e. no commit rights]

aparcar commented 3 years ago

I think there are two different types of maintainers: The meta maintainers that look at all kinds of packages and thankfully share their expertise, but also the package focused maintainers which deal with their small selection of packages and don't bother for the rest, which I think is fine.

Both approaches are fine and currently co-existing, looking at routing.git and telephony.git, neither seem excited to merge things into packages.git because there is to much happening to keep track.

Can we combine both approaches within packages.git? I'm also okay limiting things here to a small group of committers, in that case I'd like to make the list public and show the structure rather than having it somewhat in-transparent. The group of committers can then decide on new "commiters", rather than me after a 5 minute IRC conversation (the initial starter for this issue).

champtar commented 3 years ago

I had to go back to the old issue, the only problem is producing a proper script to generate CODEOWNERS file, that would improve notification precision and allow to give selective commit rights if we want.

I think we should stick to have people asking for access as an issue, it makes it easier to review someones work (OpenWrt or other projects) and is more visible than IRC. The current OpenWrt build system more or less gives RCE on any developer computer to anyone able to update a package so it's important to not give access too fast, except for that I'm all for more commiters

mstorchak commented 3 years ago

the only problem is producing a proper script to generate CODEOWNERS file, that would improve notification precision and allow to give selective commit rights if we want.

Another option is to make CODEOWNERS an opt-in list. Create an empty list and add people by accepting their PRs with changes to this list. These could be dedicated PRs or ones combined with code changes.

BKPepe commented 3 years ago

As @stangi got commit access from @aparcar with approval from @neheb a few minutes ago. Is it possible to give commit access to more people like I mentioned in my previous post?

diizzyy commented 3 years ago

All green for me fwiw

aparcar commented 3 years ago

@BKPepe sure please proceed

BKPepe commented 3 years ago

I would like to do it, but I can not as I don't have permission.

aparcar commented 3 years ago

I'll do so. Done

PolynomialDivision commented 3 years ago

I would nominate @CodeFetch

jefferyto commented 3 years ago

Apologies for the late reply - thanks @BKPepe and @aparcar for the invitation.

I think my feelings on having commit access are similar to @commodo's. The current process for making contributions works well enough for me; I don't mind waiting for someone else to review and commit my changes. I also don't foresee my level of involvement here changing much in the near future, even with commit access.

If this is acceptable then I would be happy to accept the invitation :slightly_smiling_face:

On having a policy on granting commit access for new contributors, I think the real issue is that there is no process for decision making here. I don't think the main repo is perfect but at least they have a formal voting process. Without a clear decision making process, discussions can continue indefinitely and either nothing gets done or someone with commit access will unilaterally decide to enact some change.