1 |
On 8/18/20 8:52 PM, Miroslav Šulc wrote: |
2 |
> is there a way or would it be possible to get notified on pull |
3 |
> requests that are relevant to me? though i get notifications from |
4 |
> github, i get tens to hundreds daily and most of them are irrelevant |
5 |
> to me so searching for those few that are related to me is really |
6 |
> inefficient for me. |
7 |
|
8 |
You should receive them for any team you're part of? But as you said, |
9 |
sometimes they're in the hundreds per day. The only way I'm aware to |
10 |
sort them is by configuring your e-mail client's filtering. If you use |
11 |
GMail for your devpost, it's pretty easy. |
12 |
|
13 |
|
14 |
> if a maintainer is mia and does not accept pull requests, there is |
15 |
> much lower chance to get his/her package fixed/bumped. i personally do |
16 |
> not hesitate to step up and fix a package though i do not maintain it |
17 |
> if the bug bothers me and i see no activity from the maintainer. and |
18 |
> if i can find a pull request for such a package, it could save me some |
19 |
> time. so what i had on my mind is a situation with maintainer mia + |
20 |
> no-pull-requests-policy -> worse situation than maintainer mia and |
21 |
> yes-pull-requests-policy. |
22 |
|
23 |
If you see a devaway permitting that, sure go ahead. Otherwise it's not |
24 |
different to how things are now - wait for maintainer timeout, get their |
25 |
approval in IRC or by e-mail, or ask QA to do it / permission to do it. |
26 |
|
27 |
|
28 |
>> I believe toggling the flag per-package basis is too much. Sure I can |
29 |
>> see the situation where this happens, but the point here is to enable |
30 |
>> communication between contributor and maintainer. If you're not |
31 |
>> accepting PRs to some packages, you can close the PR informing |
32 |
>> contributor about it. It'd be better than leave it to rot for months, |
33 |
>> years, with no answer. |
34 |
> |
35 |
> you know much better than me how pull requests are processed and what |
36 |
> benefits and problems those bring. for me pull requests are generally |
37 |
> good thing but sometimes when i see the quality of them, basic issues |
38 |
> not resolved like the missing signed-off-by, contributors not |
39 |
> responding and disappearing... i'm just not sure this whole effort |
40 |
> will bring some advancement, but i trust your opinion on that as you |
41 |
> are the one spending a lot of time on github. anyway, when it comes to |
42 |
> this feature mentioned above, if it might be of any use, it can work |
43 |
> as an override for package where it is specified and otherwise be |
44 |
> undefined. in the end the contributor will be interested in whether |
45 |
> the package accepts pull requests, not a dev or project. |
46 |
> |
47 |
If you see faults in the PR, please let the contributor know. It's their |
48 |
only way to improve. Yeah not everyone reads all docs, but if you work |
49 |
with them, the quality gets better. |
50 |
|
51 |
There is a reason for every PR. Nobody will get flooded by them, since |
52 |
there shouldn't be a continuous reason to push them right? And if there |
53 |
is, maybe it implies something about the current state of maintenance... |
54 |
|
55 |
And the package inherits "acceptance state" of its maintainers which'd |
56 |
then be visible, per-package. |
57 |
|
58 |
|
59 |
> can't we have a bug tracker for this webapp? i think it's so useful |
60 |
> that it would deserve such a space :-) |
61 |
|
62 |
You're asking for a tracker, just letting everyone know there is a way |
63 |
to file/list bugs for packages.gentoo.org: |
64 |
|
65 |
New bug -> Websites -> Packages. Arzano should decide whether we track |
66 |
this or not. But for sure a bug about this needs to be created, unless |
67 |
other people shoot the idea down. |
68 |
|
69 |
-- juippis |