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

[M.-A. Lemburg]

On 05.01.2016 18:50, Brett Cannon wrote:
> 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 that's the case, then it's fine.

> If people are that worried, we could do a daily dump of the data.

This would be a good idea in general. Backups are always good
to have :-)

> 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.

True.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 05 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/