Dne 18. 08. 20 v 19:06 Joonas Niilola napsal(a):
On 8/18/20 7:30 PM, Miroslav Šulc wrote:

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.
is there a way or would it be possible to get notified on pull requests that are relevant to me? though i get notifications from github, i get tens to hundreds daily and most of them are irrelevant to me so searching for those few that are related to me is really inefficient for me.

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.
if a maintainer is mia and does not accept pull requests, there is much lower chance to get his/her package fixed/bumped. i personally do not hesitate to step up and fix a package though i do not maintain it if the bug bothers me and i see no activity from the maintainer. and if i can find a pull request for such a package, it could save me some time. so what i had on my mind is a situation with maintainer mia + no-pull-requests-policy -> worse situation than maintainer mia and yes-pull-requests-policy.
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.

you know much better than me how pull requests are processed and what benefits and problems those bring. for me pull requests are generally good thing but sometimes when i see the quality of them, basic issues not resolved like the missing signed-off-by, contributors not responding and disappearing... i'm just not sure this whole effort will bring some advancement, but i trust your opinion on that as you are the one spending a lot of time on github. anyway, when it comes to this feature mentioned above, if it might be of any use, it can work as an override for package where it is specified and otherwise be undefined. in the end the contributor will be interested in whether the package accepts pull requests, not a dev or project.

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.
i agree with you, making a contribution and being ignored is demotivating.
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)


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@
does not seem to be updated or i misunderstood something. the same
goes for the list of 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

Please talk to arzano about this. Although I'm pretty sure he will read
this thread ;)
can't we have a bug tracker for this webapp? i think it's so useful that it would deserve such a space :-)
-- juippis


Reply via email to