On Tue, 5 Jan 2016 at 03:22 M.-A. Lemburg <[email protected]> wrote: > On 05.01.2016 06:53, Ezio Melotti wrote: > >> Or is there some prepackaged service that > >> we can use that will keep track of this which would cause us to not use > >> Roundup (which might be easier, but depending on the service require > >> everyone to re-sign)? There's also the issue of supporting people who > want > >> to submit code by uploading a patch to bugs.python.org but not use > GitHub. > >> Either way I don't want to have to ask everyone who submits a PR what > their > >> bugs.python.org username is and then go check that manually. > >> > > > > This also brings up another problem. > > Since the discussion about an issue happens on b.p.o and the PRs are > > submitted on GitHub, this means that: > > 1) users with only a GitHub account have to create a b.p.o account if > > they want to comment on the issue (exclusing review comments); > > 2) users with only a b.p.o account have to create a GitHub account if > > they want to review a PR; > > 3) users with both can comment on b.p.o and review on GitHub, but they > > might need to login twice. > > > > It would be better if users didn't need to create and use two separate > accounts. > > Given that we want to make it possible to move away from Github > without too much fuzz, wouldn't it be better to have the > PR discussions on b.p.o and Rietvield ? >
One of the motivating factors of this move is to get off of our fork of Rietveld, so that's not feasible. > > If we start using Github for this, we'd lose that part of the > review history when moving away. > GitHub's API allows for exporting all of the data. > > Moving from the SF issue tracker to b.p.o was a major piece of work > (mostly done by Martin von Löwis IIRC) and it's not clear how we > could retrofit those discussions into the b.p.o issue discussions. > > Perhaps we could gateway the emails that Github sends for PR > discussions back into b.p.o in some way (the emails contain the > PR number, repo name and Github account name of the sender > in the headers). > I believe GitLab has a GitHub -> GitLab migration tool that keeps PR history, so this isn't quite the issue that it initially appears to be. If people are that worried, we could do a daily dump of the data. But unless we can have all GitHub-related comments to an issue not trigger an email update I don't think that's feasible as it would mean two emails for every PR comment; one from GitHub and one from b.p.o.
_______________________________________________ core-workflow mailing list [email protected] https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
