Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

[Miroslav Šulc]

Dne 18. 08. 20 v 19:06 Joonas Niilola napsal(a):
> 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.
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)
>
> 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/proaudio@g.o/outdated)
>> does not seem to be updated or i misunderstood something. the same
>> goes for the list of bugs
>> (https://packages.gentoo.org/maintainer/proaudio@g.o/bugs)
>> which seems to be missing some bugs as my list with "Assignee:
>> proaudio@g.o" 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 ;)
can't we have a bug tracker for this webapp? i think it's so useful that 
it would deserve such a space :-)
> -- juippis

fordfrog