1 |
On 8/18/20 7:30 PM, Miroslav Šulc wrote: |
2 |
> hi, |
3 |
> |
4 |
> how would be handled cases where you and me agreed that you will take |
5 |
> care of pull requests on behalf of sound@ and proaudio@? and what if a |
6 |
> package is maintained by multiple maintainers or even some maintainers |
7 |
> and a project, each with a different preference? how that would be |
8 |
> solved to not bring in some confusion? and how about maintainers that |
9 |
> are not gentoo devs? and what if there are packages that have a |
10 |
> maintainer that is mia but has the no-accept policy set and some other |
11 |
> dev would like to fix a package that has an annoying bug (using a pull |
12 |
> request by a contributor) as the reported maintainer is mia, or a |
13 |
> contributor might want to maintain the package? and what if a |
14 |
> maintainer wants pull requests just for some packages and not for |
15 |
> others? and what if a pull request is referenced from a bug at |
16 |
> bugzilla but the maintainer does not accept pull requests? |
17 |
|
18 |
One idea for implementation would be to enable the flag in your User: |
19 |
page. Then if any member in a project has it enabled, the project would |
20 |
have it set positive as well. However it doesn't necessary directly |
21 |
translate to you you merging personal PRs -> you merging all of your |
22 |
project PRs. I also thought the project could count Yes's and No's from |
23 |
their members, printing something like "This project has a 66 % |
24 |
probability of handling Github PRs". But that'd look silly. |
25 |
|
26 |
So I think it's just simplest to enable it per-user per-project basis. |
27 |
We can all edit Project: pages, toggling the flag. If you're willing to |
28 |
look and merge sound@ PRs, you enable it for Sound project. However this |
29 |
might cause a problem when a member who enabled the flag leaves the |
30 |
project, or gets retired. But that's relatively easy to keep a track of. |
31 |
|
32 |
As for non-dev maintainers, they **require** @gentoo.org person/project |
33 |
to proxy for them. It'd be a start to mirror the project/dev option, |
34 |
since they'd be the one committing for non-dev maintainers anyway. Also |
35 |
non-dev maintainers can have their own wiki pages to toggle this. |
36 |
However I'm not aware if the linking is as simple as with @gentoo.org |
37 |
metadata info. |
38 |
|
39 |
If the current maintainer is MIA, it doesn't change anything from our |
40 |
current situation. At least it doesn't make it any worse than it is, but |
41 |
has advantages for those available. I'm sorry I may have not understood |
42 |
your question correctly here? We can claim maintainer timeout, or ask QA |
43 |
to deal with these situations. It wouldn't change. |
44 |
|
45 |
I believe toggling the flag per-package basis is too much. Sure I can |
46 |
see the situation where this happens, but the point here is to enable |
47 |
communication between contributor and maintainer. If you're not |
48 |
accepting PRs to some packages, you can close the PR informing |
49 |
contributor about it. It'd be better than leave it to rot for months, |
50 |
years, with no answer. |
51 |
|
52 |
Your last question wouldn't be any different from a current situation, |
53 |
however other devs/users can inform the contributor that this maintainer |
54 |
can't/doesn't use Github, and the PR can be closed. I'm mostly looking |
55 |
for communication here. I believe being rejected is better than being |
56 |
ignored. The bug can be dealt separately from Github PR. |
57 |
|
58 |
There's a tool that tells what PRs reference a closed bug, |
59 |
|
60 |
(ie contribution was made, but not accepted/noticed, and the bug was |
61 |
closed regardless of it) |
62 |
|
63 |
https://github.com/wimmuskee/gengee |
64 |
|
65 |
|
66 |
> |
67 |
> sorry for this flood of questions but atm it brings confusion to me |
68 |
> :-) from my point of view and personal preference, i appreciate pull |
69 |
> requests from contributors if those are of a decent quality, but for |
70 |
> me it's hard to easily find out the relevant pull requests. with the |
71 |
> new packages.gentoo.org it might be easier in the future but i'm not |
72 |
> sure yet how reliable it is atm as for example the list of outdated |
73 |
> packages for proaudio@ |
74 |
> (https://packages.gentoo.org/maintainer/proaudio@g.o/outdated) |
75 |
> does not seem to be updated or i misunderstood something. the same |
76 |
> goes for the list of bugs |
77 |
> (https://packages.gentoo.org/maintainer/proaudio@g.o/bugs) |
78 |
> which seems to be missing some bugs as my list with "Assignee: |
79 |
> proaudio@g.o" has 96 bugs atm compared to 76 bugs at |
80 |
> packages.gentoo.org. |
81 |
> |
82 |
> fordfrog |
83 |
|
84 |
Please talk to arzano about this. Although I'm pretty sure he will read |
85 |
this thread ;) |
86 |
|
87 |
-- juippis |