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

[R. David Murray]

On Thu, 11 Aug 2016 22:09:33 +0200, Maciej Szulik <soltysh at gmail.com> wrote:
> 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.

Yeah, that's one of the things that makes even using it through the
web UI problematic.  Oh well :)

--David