[core-workflow] My initial thoughts on the steps/blockers of the transition

[Brett Cannon]

On Tue, 5 Jan 2016 at 03:22 M.-A. Lemburg <mal at egenix.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160105/6b512f77/attachment.html>