Front page | perl.perl5.porters |
Postings from April 2016
Re: github contributor notices
From: Sawyer X
April 10, 2016 22:13
Re: github contributor notices
Message ID: 570AD010.email@example.com
On 04/10/2016 09:13 PM, Craig A. Berry wrote:
> On Sun, Apr 10, 2016 at 9:53 AM, Sawyer X <firstname.lastname@example.org> 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
>>> <email@example.com> 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.
>>> 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.
Wouldn't be the first time. :)
> 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.
I wasn't thinking of using that, to be honest. Just a hook that gets
called when a PR is opened (Github has that), takes that and opens an RT
ticket, and closes the original PR. That's about it.
> How does the PR capture the output of perl -V and
> the answers to the other questions that perlbug asks?
That's a very good point. It could also do other stuff instead, like
send an email to the person who opened it saying "Please refile this
with perlbug" or "Here's a ticket we opened for it, can you please add
the following details?"
Is the perl -V output of the same importance for a patch as for a bug
report? I might be wrong, but I imagine it's more important when
reporting a bug, rather than submitting a patch to fix a problem
(because that would be against blead, surely - or should be that way, at
When I want to provide a patch, what crucial information does "perlbug" add?
> 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.
I'm probably missing something. If your notifications are turned off,
replies to the ticket will not generate anything. The whole discussion
is effectively *moved* to RT.
Say Alice opens a PR. An RT ticket is opened with the patch (I assume
each commit is a patch attachment in one ticket). Bob is not in the
Github Perl org, so Bob receives no notification. Carol is on the Github
Perl org, but she has notifications turned off for it, so she does not
receive a notification. Bob and Carol are both on the p5p mailing list,
so they receive a notification from RT via the list. Alice receives an
email saying "Hey, we moved this to RT. Please join us there!"
> 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.
I assume that opening a ticket and adding attachments is covered by the
RT API and should not really change significantly. As well as the hook
for Github and API to close the issue. Also, this entire mechanism would
just be a helper for people wanting to submit PRs. No assurance of its
working state is mandatory.
> 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.
I honestly don't know if it's going to be used by anyone, which is what
will dictate if there's any value to be had with it.