[core-workflow] GitHub reviews comments on b.p.o

[Maciej Szulik]

On Tue, Aug 2, 2016 at 4:24 PM, R. David Murray <rdmurray at bitdance.com>
wrote:

> On Sat, 30 Jul 2016 23:21:07 +0200, Maciej Szulik <soltysh at gmail.com>
> 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 the amount does not matter in that
> > case, whoever is interested in looking or answering into the patch
> > will have to go to GitHub and see what exactly it's about. I'm aware
> > there are cases you just want to read the comment and don't do
> > anything yet, but these are rare cases we can initially ignore. Let's
> > start simple and we can always get back to this topic.
>
> If github comment threading were more sensible I think I'd prefer to see
> the comments reflected.  But since it *isn't* (it is pretty much useless
> outside of the web UI, and even in the web UI it is often awkward),
> I think linking to the PR is indeed probably better.
>
> Just to confirm, we are talking about a new link summarizing the comment
> activity for the past N minutes, whenever commenting activity happens,
> right?  It would be nice to link directly to the new comments, but somehow
> I doubt that is going to be possible (at least if we batch them), so we'll
> probably have to settle for just linking the summary to the PR as a whole.
>
>
Correct. The links to separate comments might be of no use after a rebase
to a PR, since they will point to hidden comments, that's why having a
single
global link is much better, because going to the PR will give you the
current
state of it.

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160811/94c86cb2/attachment.html>