On Fri, Jul 24, 2015, 09:07 Nick Coghlan <[email protected]> wrote:
On 22 July 2015 at 04:03, Brett Cannon <[email protected]> wrote: > On Mon, Jul 20, 2015 at 7:15 PM Nick Coghlan <[email protected]> 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 | [email protected] | Brisbane, Australia
_______________________________________________ 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
