Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Discontinuing the support for GitHub pull requests
Date: Fri, 03 Nov 2017 17:12:42
Message-Id: 1509729155.889.2.camel@gentoo.org
In Reply to: Re: [gentoo-project] Discontinuing the support for GitHub pull requests by Daniel Campbell
1 W dniu czw, 02.11.2017 o godzinie 20∶18 -0700, użytkownik Daniel
2 Campbell napisał:
3 > On Tue, Oct 31, 2017 at 12:17:38AM +0100, Michał Górny wrote:
4 > > [snip]
5 > >
6 > > 1. Developers who refuse to review pull requests to their packages.
7 > > Yes, I can understand that some people have their reasons for not using
8 > > GitHub. However, I do not consider it appropriate if they refuse to use
9 > > GitHub to review pull requests for their Gentoo packages but at the same
10 > > time use it for their own toy projects and/or work.
11 > >
12 > > In any case, those developers effectively mean that we either have to
13 > > close the contributions in the users' face or proxy them to maintainers.
14 > > The first solution harms contributors, the second adds a lot of work.
15 > >
16 > > 2. Developers who ignore GitHub mail for whatever reason, and expect us
17 > > to ping them on every contribution. We just don't have the resources to
18 > > track everyone who might or might not have gotten a notification, or
19 > > maybe he should be pinged twice, or maybe he doesn't want to use GitHub
20 > > except he added his account to Gentoo org for the fun of it...
21 > > [snip]
22 > >
23 >
24 > This seems like a ripe case for automation. Do you think it would be difficult
25 > to build a bot that would assign an Issue to a white-listed maintainer and print
26 > a "please file on bugzie, here's how" message if the maintainer isn't in the
27 > list? Please don't interpret this as me asking you to build something. I'm just
28 > asking for your technical opinion. It seems like someone who cares about
29 > this could put a bot together in a weekend. Am I wrong?
30 >
31 > I think it could work and allow both workflows to coexist while ensuring
32 > both platforms can interface with their users.
33 >
34 > Naturally, those who need it most should probably be building it..
35
36 It should not take more than a few hours to adjust the existing
37 scripting. However, you need to note that there is a lot of corner cases
38 to cover, like weird projects and packages with multiple maintainers.
39
40 Also, the existing script fails pretty often due to connectivity issues
41 if it lingers too long due to many pull requests being open. If you add
42 more work to it, you increase the likeliness of failure.
43
44 > .
45
46 --
47 Best regards,
48 Michał Górny