On 8/18/20 7:30 PM, Miroslav Šulc wrote: > hi, > > how would be handled cases where you and me agreed that you will take > care of pull requests on behalf of sound@ and proaudio@? and what if a > package is maintained by multiple maintainers or even some maintainers > and a project, each with a different preference? how that would be > solved to not bring in some confusion? and how about maintainers that > are not gentoo devs? and what if there are packages that have a > maintainer that is mia but has the no-accept policy set and some other > dev would like to fix a package that has an annoying bug (using a pull > request by a contributor) as the reported maintainer is mia, or a > contributor might want to maintain the package? and what if a > maintainer wants pull requests just for some packages and not for > others? and what if a pull request is referenced from a bug at > bugzilla but the maintainer does not accept pull requests?
One idea for implementation would be to enable the flag in your User: page. Then if any member in a project has it enabled, the project would have it set positive as well. However it doesn't necessary directly translate to you you merging personal PRs -> you merging all of your project PRs. I also thought the project could count Yes's and No's from their members, printing something like "This project has a 66 % probability of handling Github PRs". But that'd look silly. So I think it's just simplest to enable it per-user per-project basis. We can all edit Project: pages, toggling the flag. If you're willing to look and merge sound@ PRs, you enable it for Sound project. However this might cause a problem when a member who enabled the flag leaves the project, or gets retired. But that's relatively easy to keep a track of. As for non-dev maintainers, they **require** @gentoo.org person/project to proxy for them. It'd be a start to mirror the project/dev option, since they'd be the one committing for non-dev maintainers anyway. Also non-dev maintainers can have their own wiki pages to toggle this. However I'm not aware if the linking is as simple as with @gentoo.org metadata info. If the current maintainer is MIA, it doesn't change anything from our current situation. At least it doesn't make it any worse than it is, but has advantages for those available. I'm sorry I may have not understood your question correctly here? We can claim maintainer timeout, or ask QA to deal with these situations. It wouldn't change. I believe toggling the flag per-package basis is too much. Sure I can see the situation where this happens, but the point here is to enable communication between contributor and maintainer. If you're not accepting PRs to some packages, you can close the PR informing contributor about it. It'd be better than leave it to rot for months, years, with no answer. Your last question wouldn't be any different from a current situation, however other devs/users can inform the contributor that this maintainer can't/doesn't use Github, and the PR can be closed. I'm mostly looking for communication here. I believe being rejected is better than being ignored. The bug can be dealt separately from Github PR. There's a tool that tells what PRs reference a closed bug, (ie contribution was made, but not accepted/noticed, and the bug was closed regardless of it) https://github.com/wimmuskee/gengee > > sorry for this flood of questions but atm it brings confusion to me > :-) from my point of view and personal preference, i appreciate pull > requests from contributors if those are of a decent quality, but for > me it's hard to easily find out the relevant pull requests. with the > new packages.gentoo.org it might be easier in the future but i'm not > sure yet how reliable it is atm as for example the list of outdated > packages for proaudio@ > (https://packages.gentoo.org/maintainer/proau...@gentoo.org/outdated) > does not seem to be updated or i misunderstood something. the same > goes for the list of bugs > (https://packages.gentoo.org/maintainer/proau...@gentoo.org/bugs) > which seems to be missing some bugs as my list with "Assignee: > proau...@gentoo.org" has 96 bugs atm compared to 76 bugs at > packages.gentoo.org. > > fordfrog Please talk to arzano about this. Although I'm pretty sure he will read this thread ;) -- juippis
signature.asc
Description: OpenPGP digital signature
