Front page | perl.perl5.porters |
Postings from April 2016
Re: github contributor notices
Thread Previous
|
Thread Next
From:
Craig A. Berry
Date:
April 10, 2016 19:13
Subject:
Re: github contributor notices
Message ID:
CA+vYcVz2bG_o5nCvKmeD-XhHeRFtPFFAi=Hm5PqU_1rj1kjTrg@mail.gmail.com
On Sun, Apr 10, 2016 at 9:53 AM, Sawyer X <xsawyerx@gmail.com> wrote:
>
>
> On 04/10/2016 01:27 AM, Craig A. Berry wrote:
>> On Sat, Apr 9, 2016 at 2:11 PM, Ivan Pozdeev via perl5-porters
>> <perl5-porters@perl.org> wrote:
>>> Github PR are yet another channel of contribution. Some may prefer its
>>> interface to p5p.
>>> Your incentive appears to be to avoid splitting the discussion between
>>> multiple places.
>>> If so, why not have them replicated here like RT already is?
>>> https://github.com/google/pull-request-mailer looks like the thing made with
>>> exactly this in mind.
>> the
>> thought of an automated mailer on GitHub sending patches to RT, and
>> then (much worse) the two automated systems managing responses gives
>> me a headache. The maintainers of RT and the perl.org mailing lists
>> have enough things to give them nightmares already.
>
> Github notifications can be fully disabled so no one gets any
> notification except people who explicitly register for them.
>
> What if, when you open a Pull Request on Github, it creates an RT ticket
> from it and closes the Pull Request, citing the new RT ticket?
>
> To a further extent (the virtue of which can possibly be determined by
> someone else), we could synchronize all the communication between a Pull
> Request and RT automatically. A comment on either is copied
> automatically to the other. Only those explicitly registering to Github
> notifications get a notification, such as those not on the mailing list.
>
> The mailing list only gets updates through the regular RT forwarding
> mechanism. Any PR thus has a corresponding RT ticket.
I think that this is a lot harder to do right than you seem to think.
The pull-request-emailer cited above turns a PR into a patch series;
does that mean one e-mail per commit? If so, sending those to RT is
going to create a new ticket for each commit, which is definitely not
something we want. How does the PR capture the output of perl -V and
the answers to the other questions that perlbug asks? How do you
prevent the automated systems' auto-responders from responding to each
other's auto-responses ad infinitum? Those and many other issues like
them would need to be studied and a working set-up created and tested.
Which is a lot of work for Someone Else.
Even if such a thing were being proposed with a working demonstration
(which it's not) implementing it would add complexity in that anytime
someone makes an enhancement to the RT set-up or upgrades to a new
version of RT, the implications for the GitHub gateway would have to
be sussed out and tested.
If people really think this is important, do pursue it, but so far no
one's made much of a case that it's desirable, much less doable, much
less actually done it. And I should point out, I'm not the one who
needs to be convinced; that would be the maintainers of the RT
instance, who probably only dip into p5p occasionally.
Thread Previous
|
Thread Next