[core-workflow] Starting the improved workflow discussion again

[Brett Cannon]

 On Fri, Jul 24, 2015, 09:07 Nick Coghlan <ncoghlan at gmail.com> wrote:

On 22 July 2015 at 04:03, Brett Cannon <bcannon at gmail.com> wrote:
> On Mon, Jul 20, 2015 at 7:15 PM Nick Coghlan <ncoghlan at gmail.com> wrote:
>> I think you're conflating some different issues here, at least two of
>> which are worth separating out from each other:
>>
>> 1. Completely online workflow for documentation editing
>> 2. Pre-commit CI for CPython
>
>
> I wasn't conflating them so much as not worrying about #1 as I know that's
> not a hard problem to solve like the CPython-specific workflow is.

Weelll, it's harder than I'd like, because software is software, and
companies are companies, and I have some pretty major trust issues
when it comes to the latter :)

>> This means that for forge.python.org, I think "What about CPython?"
>> should be something we take into account as a "What's next?" for the
>> service, but our near term focus should be on making things like the
>> developer guide and PEPs trivial to suggest edits to, trivial to
>> approve edits to, and trivial to grant approval rights over. Those
>> levels of access (who can suggest edits, who can approve edits, who
>> can approve edit rights for others) should also all be completely
>> transparent and changes in them should be tracked automatically rather
>> than requiring manual updates to a text file.
>
>
> OK, then let's choose the devguide or the PEPs to test Kalithea out on and
> see how it goes since no one has experience with the service while I bet
> everyone has experience with at least GitHub. If you can get whomever has
> done the most amount of work on the devguide lately to sign off on it --
> probably Carol Willing -- then I say get a test instance of
forge.python.org
> up for the devguide and let's see what working with Kalithea is like (and
it
> also gets us more new contributor feedback than the PEPs would while also
> not frustrating Guido when he deals with peps@ =).

This is actually where the "What about BitBucket as an interim
solution?" thread that spawned Donald's GitHub+Phabricator
counter-proposal came from. I already know there are two major
limitations of Kallithea that we'd likely want to address before
adopting it as our primary repo hosting solution, even for the support
repos:

1. Social auth support, so folks can log in with
GitHub/BitBucket/Twitter/Facebook/Google et al credentials rather than
having to create yet another account.
2. Online creation and acceptance of change proposals from third
parties (If I understand Kallithea's current capabilities correctly,
you can edit directly on your own repos, but there's no counterpart to
the "fork->edit->PR" workflow GitHub & BitBucket offer for submitting
online-only changes to other people's repos)

Addressing the first one may also involve a Pylons -> Pyramid upgrade
for Kallithea. I'd be prepared to coordinate a grant proposal to the
PSF to fund that work (hopefully in collaboration with the folks from
Agendaless, since I spoke to them about the prospect at PyCon US), but
I wouldn't want to commit funds to it without some way of ensuring
we're happy with a pull request based workflow first.

Even beyond that, though, I'm also looking at the workflow the
Kallithea team *themselves* are currently using, and thinking "Hmm, I
quite like that approach". What they're doing is using BitBucket as
their "working repo", and https://kallithea-scm.org/repos/ as their
"repository of record".

Since the long term outcome I'd like to see us get to is "able to
accept PRs on both GitHub and BitBucket, repository of record on PSF
hosted infrastructure", the transition plan that is starting to make
sense to me is:

1. Move one or two support repos to the PSF BitBucket account,
automatically update from there back to the existing repos on
hg.python.org (we'd revoke direct commit access to the latter, but the
build processes hanging off them would still trigger when commits were
pushed by the automated sync)
2. Work with that model for a while, establish that folks are happy
with the PR based workflow
3. Approach forge.python.org as an easier to manage hg.python.org,
rather than as the key enabler in offering pull request based
workflows for third party contributors to the support repos
4. The main capability of interest with Kallithea would then be
gaining support for "remote PRs" where folks actually submitted the PR
through GitHub or BitBucket, but it could be processed by reviewers in
Kallithea. That capability doesn't exist yet (in any tool), but it's
one Mozilla are also interested in.

 Basically Kalithea becomes a common frontend to bitbucket and github where
we generate patches from PRs on either site and work with them on our end
for reviews, applying them to our repo of record, etc. How would we handle
changes that require custom fixes in two branches? They just fix it in both
and we automatically handle the merge/revert steps?

In this model, the main rationale for "Why BitBucket rather than
GitHub?" is purely and simply "because migrating from Hg to git
doesn't buy us enough for the cost in time and effort given that most
repos are going to be remaining on hg.python.org".

I guess I should update my workflow PEP to reflect the above changes
in my thinking over the past several months...

 Yes please. :)

-Brett

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150725/415ee37b/attachment.html>