On Thu, 11 Aug 2016 22:09:33 +0200, Maciej Szulik wrote:
> On Tue, Aug 2, 2016 at 4:24 PM, R. David Murray
> wrote:
>
> > On Sat, 30 Jul 2016 23:21:07 +0200, Maciej Szulik
> > wrote:
> > > I'm leaning towards just adding an information who left the comment
> > > and a link to the PR. I agree wi
On Tue, Aug 2, 2016 at 4:24 PM, R. David Murray
wrote:
> On Sat, 30 Jul 2016 23:21:07 +0200, Maciej Szulik
> wrote:
> > I'm leaning towards just adding an information who left the comment
> > and a link to the PR. I agree with Senthil that gh comments,
> > especially those coming from reviews ha
On Sat, 30 Jul 2016 23:21:07 +0200, Maciej Szulik wrote:
> I'm leaning towards just adding an information who left the comment
> and a link to the PR. I agree with Senthil that gh comments,
> especially those coming from reviews have code context, which will get
> lost when copying over. Besides t
I'm leaning towards just adding an information who left the comment and a
link to
the PR. I agree with Senthil that gh comments, especially those coming from
reviews
have code context, which will get lost when copying over. Besides the
amount does
not matter in that case, whoever is interested in l
There has been talk in the past of setting up a cronjob somewhere that
backs up all data stored at GitHub in some way for contingency purposes. I
think it's a totally reasonable thing to do, but I don't plan to hold up
the migration for it.
On Fri, 29 Jul 2016 at 04:09 Petr Viktorin wrote:
> On
On 07/28/2016 06:21 PM, Senthil Kumaran wrote:
On Thu, Jul 28, 2016 at 7:48 AM, R. David Murray wrote:
The obvious alternative is to just post a link to the PR with some
summary about what was posted (perhaps who and how many comments?). I
don't have an opinion at this point which would be bet
On Thu, Jul 28, 2016 at 7:48 AM, R. David Murray wrote:
> The obvious alternative is to just post a link to the PR with some
> summary about what was posted (perhaps who and how many comments?). I
> don't have an opinion at this point which would be better, but the core
> of the proposed patch wo
On Wed, 27 Jul 2016 16:08:52 -0700, Senthil Kumaran wrote:
> On Wed, Jul 27, 2016 at 2:57 PM, R. David Murray
> wrote:
> > The general consensus (a while back) was that the fact that reitveld
> > doesn't update the bug tracker issue is a bug, and we're trying to fix
> > that :)
>
> Haha. Intere
On Wed, 27 Jul 2016 16:08:52 -0700, Senthil Kumaran wrote:
> On Wed, Jul 27, 2016 at 2:57 PM, R. David Murray
> wrote:
> > The general consensus (a while back) was that the fact that reitveld
> > doesn't update the bug tracker issue is a bug, and we're trying to fix
> > that :)
>
> Haha. Intere
On Wed, Jul 27, 2016 at 2:57 PM, R. David Murray wrote:
> The general consensus (a while back) was that the fact that reitveld
> doesn't update the bug tracker issue is a bug, and we're trying to fix
> that :)
Haha. Interesting.
Github sends one email for every comment, it does not have a "draft
On Wed, 27 Jul 2016 14:00:09 -0700, Senthil Kumaran wrote:
> On Wed, Jul 27, 2016 at 1:00 PM, Anish Shah wrote:
> > it checks if any "GitHub" comment was added in last "X" minutes. If no
> > GitHub comments were added, then it adds that comment to the linked issue.
>
> I guess, you meant, "if a
On Wed, Jul 27, 2016 at 1:00 PM, Anish Shah wrote:
> it checks if any "GitHub" comment was added in last "X" minutes. If no
> GitHub comments were added, then it adds that comment to the linked issue.
I guess, you meant, "if any comments were added to GitHub issues".
So, it does polling instead
Hello everyone,
I'm working on GitHub integration as a part of GSoC. One of my tasks was to
show GitHub review comments on b.p.o.
Here is how I did it :-
I wrote a handler to handle GitHub PR review/diff comments event using
webhooks. If a b.p.o issue is linked to a PR, then it checks if any
"Git
13 matches
Mail list logo
