Front page | perl.perl5.porters |
Postings from April 2016
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 thing is, patches need to go to RT first so they can be tracked > and only then forwarded to the mailing list for discussion. But when you create a new ticket (with patch or not), it goes to the mailing list anyway. Some of the discussions happen over RT, some over pure mailing list, but all of them appear on the mailing list just the same, no? In that case, opening an issue on RT equals sending the mailing list as well, right? > But 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.Thread Previous | Thread Next