git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Emily Shaffer <emilyshaffer@google.com>, git@vger.kernel.org
Subject: Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?
Date: Thu, 21 Nov 2019 05:54:14 -0500	[thread overview]
Message-ID: <20191121105414.GA16238@sigill.intra.peff.net> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1911181930290.46@tvgsbejvaqbjf.bet>

On Mon, Nov 18, 2019 at 07:37:57PM +0100, Johannes Schindelin wrote:

> Yeah, it wasn't easy. But then, who does not like a little challenge,
> especially the challenge to test things outside of production? So here
> is a PR: https://github.com/gitgitgadget/gitgitgadget/pull/148
> 
> I trust everybody with even rudimentary Javascript skills to be able to
> provide useful feedback on that PR.

Wow, thanks for working on this! I don't know that I'd call my
javascript skills even rudimentary, but I did give it a look. The real
challenge to me is not the individual lines of code, but understanding
how the Azure Pipelines and GitHub App systems fit together. So I didn't
see anything wrong, but I also know very little about those systems.

Likewise, the explanations in your comments and commit messages all made
sense to me. But that may also be a false sense of security. You nicely
led me through reading the patches, but the likely bug would probably be
one you did not even anticipate. ;)

> To build some confidence in my patches (as you probably know, I do not
> trust reviews as much as I trust real-life testing, although I do prefer
> to have both) I "kind of" activated it on my fork, limited to act only
> on comments _I_ made on PRs (and sending only to me instead of the
> list), and it seems to work all right, so far. I cannot say for sure
> whether it handles the PR labels correctly, but I guess time will tell,
> and I will fix bugs as quickly as I can.

Yeah, that makes sense to me. Going from one repo to three is not much
worse than going to two, so it's good to have a testing area, too.

Do you want any third-party testing there (e.g., a user who isn't you
making a PR against dscho/git)?

> Question is: should I turn this thing on? I.e. install that
> GitGitGadget-Git App on https://github.com/git/git? This would allow
> GitHub users to `/submit` directly from PRs opened in that repository. I
> am sure that there are a few kinks to work out, but I do think that it
> should not take long to stabilize.

I'd say "yes". The status quo is probably worse than a system with a few
bugs. The worst case if it's disastrously wasting submitter's time is
that we turn it back off, but I have faith that you'd just fix the bugs
before then anyway.

Is the existing Pipelines integration enough for you to turn it on for
git/git, or do I need to tweak any settings?

-Peff

  reply	other threads:[~2019-11-21 10:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-09  2:00 Should we auto-close PRs on git/git? Emily Shaffer
2019-11-09  4:55 ` Junio C Hamano
2019-11-13  5:29   ` Stephen Smith
2019-11-12 19:11 ` Johannes Schindelin
2019-11-13  1:10   ` Jeff King
2019-11-13 12:04     ` Johannes Schindelin
2019-11-14  7:41       ` Jeff King
2019-11-14 23:03         ` Johannes Schindelin
2019-11-18 18:37           ` GitGitGadget on git/git, was " Johannes Schindelin
2019-11-21 10:54             ` Jeff King [this message]
2019-11-22 13:50               ` Johannes Schindelin
2019-11-22 14:43                 ` Johannes Schindelin
2019-11-25 14:30                 ` Jeff King
2019-11-26 20:55                   ` Johannes Schindelin
2019-11-26 21:56                     ` Eric Wong
2019-11-26 22:22                       ` Johannes Schindelin
2019-11-26 22:40                         ` Eric Wong
2019-11-26 22:52                           ` Johannes Schindelin
2019-11-26 23:58                             ` Eric Wong
2019-11-27  1:52                       ` Junio C Hamano
2019-11-27  2:37                         ` Eric Wong
2019-11-13 21:09   ` Emily Shaffer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191121105414.GA16238@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).