Gentoo Archives: gentoo-dev

From: Joonas Niilola <juippis@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
Date: Tue, 18 Aug 2020 18:12:06
Message-Id: 86bb3f9b-e18e-001e-bc70-3767d99bd2d5@gentoo.org
In Reply to: Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag by "Miroslav Šulc"
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

Attachments

File name MIME type
signature.asc application/pgp-signature