[Mobile-sig] Next Steps for "Working" Port

[Cyd Haselton]

Yeah, I was afraid you were going to say that.  I[ll grab the Mercurial source today and get started.

On February 24, 2015 8:35:51 AM CST, Wes Turner <wes.turner at gmail.com> wrote:
>If git is already ported to KBOX, that might be easiest; but it's
>probably
>worth it to try and install Hg:
>
>* CPython core is Hg
>* I find it easiest to maintain a stack of changing patches with the Hg
>MQ
>extension, which is plain python (esp. with TortoiseHg)
>* Hg core does build C extensions, which probably compile with KBOX GCC
>  * https://pip.pypa.io/en/latest/installing.html
>  * pip install mercurial
>* An Hg MQ patch queue can be separately version controlled (and e.g.
>hosted w/ BitBucket as something like 'cpython-android-patches')
>pending
>review and merge back into default if at all possible
>
>Either way, a branch or patch queue might need to be rebased if the
>underlying code changes.
>
>Many CPython core devs do seem to prefer Hg.
>
>See "Docs:" https://westurner.github.io/tools/#version-control-systems
>
>hg clone https://hg.python.org/cpython
>cd cpython
>Hg tags
>Hg update -C -r tagstr
># -C clears any changes in the working directory
>
># w/ a branch
>Hg branch newbranchname
># add a commit
>Hg status
>Hg diff
>Hg add file names
>Hg status
>Hg diff
>Hg commit
># repeat
>Hg push
>
># w/ mq
># add mq ext to ~/.hgrc
># create .hg/patches
>Hg qinit -c
># create a new patch
>Hg qnew newpatchname.diff
>Hg add file names
>Hg diff
>Hg qdiff
>Hg qrefresh
>Hg qcommit
># repeat
>Hg qpush
>
>Hg help qimport
>
>From
>http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html
>:
>
>> If you receive a patch from someone that you want to add to your
>patch
>queue, and the patch needs a strip count other than one, you cannot
>just
>qimport the patch, because qimport does not yet have a -p option (see
>issue
>311).
>
>... I'm on my phone, so 'Hg' should be 'hg'
>On Feb 24, 2015 7:53 AM, "Cyd Haselton" <chaselton at gmail.com> wrote:
>
>> Wes, et. al.
>> What would be the recommended route...of the ones you mentioned...
>> assuming the following:
>> 1) Steep learning curve for git/hg VCS (near-zero knowledge for both)
>> 2) Limited amount of time.
>>
>> I've submitted a meta-issue at bugs.python.org (
>> http://bugs.python.org/issue23496) but I'm now debating in which of
>the
>> following to invest time and effort:
>> a) clean up and submit patches for the existing issue and write more
>> detailed build instructions
>> b) port Mercurial to the KBOX android env, learn Mercurial, and
>create a
>> hg branch for android
>> c) Learn git and work with the existing KBOX android port of git to
>create
>> a git branch for android
>>
>> Addional input/suggestions welcome
>>
>> On February 21, 2015 4:44:25 PM CST, Wes Turner
><wes.turner at gmail.com>
>> wrote:
>>>
>>> One could:
>>>
>>> * Submit a group of patches as attachments on a bug in the issue
>trackers
>>> and link to the patches (in sequence, if necessary) [described in
>detail in
>>> the devguide] and hope that others can reproduce the build
>>>
>>> * Create a git branch and a GitHub pull request [there are currently
>a
>>> few PRs at gh:python/cpython]
>>>   * http://documentup.com/skwp/git-workflows-book
>>>   * If there was a repository PR hook, the CI system would build the
>code
>>> on each push to a PR branch (such as w/ buildbot)
>>> * Create a git patch series with git-guilt
>>>
>>> * Create an hg branch (or bookmark, if you're working with hg-git
>and
>>> want to approximate git branches) and a bitbucket pull request
>[there are
>>> currently zero PRs at bb:mirror/cpython]
>>> * Create a patch queue with a series of patches w/ Mercurial MQ:
>>>   *
>>>
>http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html
>>>
>>> ... I've collected a number of VCS docs links here:
>>> https://westurner.github.io/tools/#version-control-systems
>>>
>>> On Fri, Feb 20, 2015 at 6:18 AM, Cyd Haselton <chaselton at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On February 20, 2015 1:57:43 AM CST, Ethan Furman
><ethan at stoneleaf.us>
>>>> wrote:
>>>> >On 02/19/2015 11:22 PM, Wes Turner wrote:
>>>> >> On Fri, Feb 20, 2015 at 12:02 AM, Ethan Furman wrote:
>>>> >
>>>> >>> The goal is make mobile support part of Python trunk.
>>>> >
>>>> >> * https://docs.python.org/devguide/index.html#contributing
>>>> >>   * Re: Android buildbot support:
>>>>
>>https://mail.python.org/pipermail/mobile-sig/2015-January/000022.html
>>>> >> * https://github.com/python/cpython/pulls
>>>> >> * https://bitbucket.org/mirror/cpython/pull-requests
>>>> >
>>>> >And exactly what was that almost-entirely-context-free bulleted
>list
>>>> >supposed to explain?
>>>> >
>>>> >--
>>>> >~Ethan~
>>>> >
>>>>
>>>> Technically the first two were links to helpful information about
>>>> contributing towards CPython.
>>>>
>>>> I''m assuming the last two were links to places to host the port. 
>While
>>>> I have ported git to this device I've limited experience with using
>it so
>>>> instructions would also have been helpful...though I can find them
>on my
>>>> own.
>>>> >
>>>> >
>>>>
>>------------------------------------------------------------------------
>>>> >
>>>> >_______________________________________________
>>>> >Mobile-sig mailing list
>>>> >Mobile-sig at python.org
>>>> >https://mail.python.org/mailman/listinfo/mobile-sig
>>>>
>>>> --
>>>> Sent from my Android device with K-9 Mail. Please excuse my
>brevity.
>>>> _______________________________________________
>>>> Mobile-sig mailing list
>>>> Mobile-sig at python.org
>>>> https://mail.python.org/mailman/listinfo/mobile-sig
>>>>
>>>
>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/mobile-sig/attachments/20150225/b4bdbb6d/attachment.html>