<p dir="ltr"><br>
</p>
<p dir="ltr"></p>
<p dir="ltr">On Fri, Jul 24, 2015, 09:07 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:</p>
<blockquote><p dir="ltr">On 22 July 2015 at 04:03, Brett Cannon <<a href="mailto:bcannon@gmail.com">bcannon@gmail.com</a>> wrote:<br>
> On Mon, Jul 20, 2015 at 7:15 PM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>> I think you're conflating some different issues here, at least two of<br>
>> which are worth separating out from each other:<br>
>><br>
>> 1. Completely online workflow for documentation editing<br>
>> 2. Pre-commit CI for CPython<br>
><br>
><br>
> I wasn't conflating them so much as not worrying about #1 as I know that's<br>
> not a hard problem to solve like the CPython-specific workflow is.</p>
<p dir="ltr">Weelll, it's harder than I'd like, because software is software, and<br>
companies are companies, and I have some pretty major trust issues<br>
when it comes to the latter :)</p>
<p dir="ltr">>> This means that for <a href="http://forge.python.org">forge.python.org</a>, I think "What about CPython?"<br>
>> should be something we take into account as a "What's next?" for the<br>
>> service, but our near term focus should be on making things like the<br>
>> developer guide and PEPs trivial to suggest edits to, trivial to<br>
>> approve edits to, and trivial to grant approval rights over. Those<br>
>> levels of access (who can suggest edits, who can approve edits, who<br>
>> can approve edit rights for others) should also all be completely<br>
>> transparent and changes in them should be tracked automatically rather<br>
>> than requiring manual updates to a text file.<br>
><br>
><br>
> OK, then let's choose the devguide or the PEPs to test Kalithea out on and<br>
> see how it goes since no one has experience with the service while I bet<br>
> everyone has experience with at least GitHub. If you can get whomever has<br>
> done the most amount of work on the devguide lately to sign off on it --<br>
> probably Carol Willing -- then I say get a test instance of <a href="http://forge.python.org">forge.python.org</a><br>
> up for the devguide and let's see what working with Kalithea is like (and it<br>
> also gets us more new contributor feedback than the PEPs would while also<br>
> not frustrating Guido when he deals with peps@ =).</p>
<p dir="ltr">This is actually where the "What about BitBucket as an interim<br>
solution?" thread that spawned Donald's GitHub+Phabricator<br>
counter-proposal came from. I already know there are two major<br>
limitations of Kallithea that we'd likely want to address before<br>
adopting it as our primary repo hosting solution, even for the support<br>
repos:</p>
<p dir="ltr">1. Social auth support, so folks can log in with<br>
GitHub/BitBucket/Twitter/Facebook/Google et al credentials rather than<br>
having to create yet another account.<br>
2. Online creation and acceptance of change proposals from third<br>
parties (If I understand Kallithea's current capabilities correctly,<br>
you can edit directly on your own repos, but there's no counterpart to<br>
the "fork->edit->PR" workflow GitHub & BitBucket offer for submitting<br>
online-only changes to other people's repos)</p>
<p dir="ltr">Addressing the first one may also involve a Pylons -> Pyramid upgrade<br>
for Kallithea. I'd be prepared to coordinate a grant proposal to the<br>
PSF to fund that work (hopefully in collaboration with the folks from<br>
Agendaless, since I spoke to them about the prospect at PyCon US), but<br>
I wouldn't want to commit funds to it without some way of ensuring<br>
we're happy with a pull request based workflow first.</p>
<p dir="ltr">Even beyond that, though, I'm also looking at the workflow the<br>
Kallithea team *themselves* are currently using, and thinking "Hmm, I<br>
quite like that approach". What they're doing is using BitBucket as<br>
their "working repo", and <a href="https://kallithea-scm.org/repos/">https://kallithea-scm.org/repos/</a> as their<br>
"repository of record".</p>
<p dir="ltr">Since the long term outcome I'd like to see us get to is "able to<br>
accept PRs on both GitHub and BitBucket, repository of record on PSF<br>
hosted infrastructure", the transition plan that is starting to make<br>
sense to me is:</p>
<p dir="ltr">1. Move one or two support repos to the PSF BitBucket account,<br>
automatically update from there back to the existing repos on<br>
<a href="http://hg.python.org">hg.python.org</a> (we'd revoke direct commit access to the latter, but the<br>
build processes hanging off them would still trigger when commits were<br>
pushed by the automated sync)<br>
2. Work with that model for a while, establish that folks are happy<br>
with the PR based workflow<br>
3. Approach <a href="http://forge.python.org">forge.python.org</a> as an easier to manage <a href="http://hg.python.org">hg.python.org</a>,<br>
rather than as the key enabler in offering pull request based<br>
workflows for third party contributors to the support repos<br>
4. The main capability of interest with Kallithea would then be<br>
gaining support for "remote PRs" where folks actually submitted the PR<br>
through GitHub or BitBucket, but it could be processed by reviewers in<br>
Kallithea. That capability doesn't exist yet (in any tool), but it's<br>
one Mozilla are also interested in.</p>
</blockquote>
<p dir="ltr"></p>
<p dir="ltr">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?<br>
</p>
<blockquote><p dir="ltr"></p>
<p dir="ltr">In this model, the main rationale for "Why BitBucket rather than<br>
GitHub?" is purely and simply "because migrating from Hg to git<br>
doesn't buy us enough for the cost in time and effort given that most<br>
repos are going to be remaining on <a href="http://hg.python.org">hg.python.org</a>".</p>
<p dir="ltr">I guess I should update my workflow PEP to reflect the above changes<br>
in my thinking over the past several months...</p>
</blockquote>
<p dir="ltr"></p>
<p dir="ltr">Yes please. :)</p>
<p dir="ltr">-Brett<br>
</p>
<blockquote><p dir="ltr"></p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</p>
</blockquote>
<p dir="ltr"><br>
</p>