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 |