jython-dev

[Jython-dev] Jython 3: greenhorn questions from an old hand

[Jeff A. <ja...@fa...>]

With 2.7.1 seemingly on its release journey, I have a bit of time to 
hack on Jython 3.  A lot has been done to Jython 3 since it forked from 
2, so I have some really newbie questions:

  * Is https://github.com/jython/jython3 the official reference
    repository? (Is https://hg.python.org/sandbox/jython3 dead?)
  * Are we still building with Ant? (It didn't for me on Windows, and I
    thought I'd fix that first.) BTW, this is a question about now, not
    what we'd like to do in future.
  * Versions: Java 8, and Python 3.5?
  * Although I believe I could commit directly to
    https://github.com/jython/jython3, or a branch in there, do we agree
    a better practice is to fork, branch and create a PR for a "feature"
    (groups of related commits)? Even if I then accept my own PR, it
    seems to give us a better audit trail, integration test, squash
    point, etc.. A separate thread/discussion is due about workflow,
    naming, etc..
  * Do we agree that our aim is to run the CPython regression tests with
    as few skips, exclusions and replacement tests as possible?
  * Does anyone have code stored up that I risk duplicating? (E.g.
    Somewhere, Darjus mentioned ANTLR4 migration.) Otherwise I'll just
    start with things I know about (bytes and strings, buffer interface,
    io, import perhaps), driven by getting Py3k tests to pass honestly.

I will averaging much fewer than 3 commits a day. ;)

-- 

Jeff Allen

Re: [Jython-dev] Jython 3: greenhorn questions from an old hand

[<fwi...@gm...>]

On Mon, May 29, 2017 at 3:07 AM, Jeff Allen <ja...@fa...> wrote:
> With 2.7.1 seemingly on its release journey, I have a bit of time to hack on
> Jython 3.  A lot has been done to Jython 3 since it forked from 2, so I have
> some really newbie questions:
>
>  * Is https://github.com/jython/jython3 the official reference
>    repository? (Is https://hg.python.org/sandbox/jython3 dead?)
Yes, the github repo is the right one to look at. In the beginning of
Isaiah Peng's amazing contributions, I reviewed his commits carefully.
Things where improving so much so fast that I just let them go after a
while. I'm sure there will be some places where we will want to adjust
things. I know there are some commits in there for convenience that I
wouldn't want pulled over as is (for example src/com/ziclix/ and
src/org/python/indexer/ where removed - I'd prefer that we move them
to their own directories like we do with installer/. In the case of
ziclix, I'd like to eventually replace those with
https://bitbucket.org/clach04/jyjdbc/ but it isn't a full replacement
yet (I have permission from the author, my fault that it isn't in
yet).

>  * Are we still building with Ant? (It didn't for me on Windows, and I
>    thought I'd fix that first.) BTW, this is a question about now, not
>    what we'd like to do in future.
Yes, we are still on ant for Jython3

>  * Versions: Java 8, and Python 3.5?
I'm for aggressively using the latest Java for Jython3, pretty much
whatever is the latest when we actually release. Given how big of a
task this will be, I'm sure that will be at least Java 9 in the end
:). I'm pretty sure the current Jython3 is focused on 3.5, but I'd be
fine with pointing to 3.6. Once we are serious about Jython3, we
probably should pick a version and see it through, as it definitely
takes more work to switch Python versions vs Java versions.

>  * Although I believe I could commit directly to
>    https://github.com/jython/jython3, or a branch in there, do we agree
>    a better practice is to fork, branch and create a PR for a "feature"
>    (groups of related commits)? Even if I then accept my own PR, it
>    seems to give us a better audit trail, integration test, squash
>    point, etc.. A separate thread/discussion is due about workflow,
>    naming, etc..
That sounds good to me. I haven't studied CPython's workflow for
github, but in general I think we should try to do what they do.

>  * Do we agree that our aim is to run the CPython regression tests with
>    as few skips, exclusions and replacement tests as possible?
Yes, and one of my dream projects is to get as many of our changes
into CPython's standard lib as possible, with an ultimate goal of
removing our own Lib/ directory altogether.

>  * Does anyone have code stored up that I risk duplicating? (E.g.
>    Somewhere, Darjus mentioned ANTLR4 migration.) Otherwise I'll just
>    start with things I know about (bytes and strings, buffer interface,
>    io, import perhaps), driven by getting Py3k tests to pass honestly.
Not me :)

>
> I will averaging much fewer than 3 commits a day. ;)
>
> --
>
> Jeff Allen
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

[Jython-dev] The CPython workflow on GitHub

[Jeff A. <ja...@fa...>]

On 29/05/2017 18:30, fwi...@gm... wrote:
> On Mon, May 29, 2017 at 3:07 AM, Jeff Allen <ja...@fa...> wrote:
>>   * Although I believe I could commit directly to
>>     https://github.com/jython/jython3, or a branch in there, do we agree
>>     a better practice is to fork, branch and create a PR for a "feature"
>>     (groups of related commits)? Even if I then accept my own PR, it
>>     seems to give us a better audit trail, integration test, squash
>>     point, etc.. A separate thread/discussion is due about workflow,
>>     naming, etc..
> That sounds good to me. I haven't studied CPython's workflow for
> github, but in general I think we should try to do what they do.
>
Since I wrote, I've been looking at CPython's workflow now based on GitHub.

For the contributor there are straightforward instructions here: 
https://docs.python.org/devguide/ that include fork, branch and PR as I 
expected. Interestingly we're asked to raise an issue on tracker at 
bugs.python.org, not at GitHub, so it's not just a repository of 
pre-existing issues. Here's an example of that working: 
https://github.com/python/cpython/pull/1853

There are some helpful bots, including an integration with 
bugs.python.org that checks for a contributor agreement. I think we 
could not copy this unless we bring our tracker up to the same state as 
the CPython one. I like the bot that @mentions core developers as 
reviewers, based on who worked on the files you touched.

Behind the scenes it is more complicated. A description of the branching 
and tagging is here: 
https://docs.python.org/devguide/devcycle.html#branches, including some 
rules about what alpha, beta, RC should mean in terms of acceptable 
commits. This all looks very sensible to me and I imagine it is 
essentially the same as it was for Mercurial.

More examples ...

Here Serhiy Storchaka makes a PR for a change consisting of (as I write) 
a couple of commits. (https://github.com/python/cpython/pull/1851) Even 
though he is a core developer, and the master branch is the active 
development branch, the work originates on a feature branch in his own 
forked repo. This gives us a chance to comment and him a chance to see 
it tested by Travis etc.. If I've understood the rules, Serhiy would be 
able to merge this into the master branch on his own approval.

In another example, the feature branch is on the central repository 
(https://github.com/python/cpython/pull/1855). I think Alex has got the 
process wrong, and it should have been on his own fork, but maybe 
there's a good reason, and I think there's no permanent harm.

Here's a more complicated example in which a change from a contributor 
is committed on master (by Serhiy) and then cherry-picked by Mariatta 
onto the 2.7, 3.5 and 3.6 branches. 
(https://github.com/python/cpython/pull/1019) This picking happens via 
branches on her own repository. The merge doesn't go smoothly on 2.7, 
but the problem is resolved with help from Serhiy. 
(https://github.com/python/cpython/pull/1289) Thus in spite of the 
difficulty, nothing hits the 2.7 branch until it is correct. Mariatta's 
branches are not visible any more since she is able to delete them after 
the merge.

Jeff

Re: [Jython-dev] Wording in readme

[Stefan R. <Ste...@gm...>]

Frank,
right after your recent commits I saw the text snippet in the readme.txt:

Along with language and runtime compatibility with CPython
2.7.1, Jython 2.7 provides substantial support of the Python


I think the explicit reference to CPython 2.7.1 is misleading. It implies that Jython micro version aligns with CPython micro version and IIRC we recently agreed that this cannot be the case.

Maybe it should better read:

Along with language and runtime compatibility with CPython
2.7, Jython 2.7.1 provides substantial support of the Python

I suppose such a change needn't interrupt the pending rc2 release. Readme adjustments should be fine between RC2 and final.

-Stefan

Re: [Jython-dev] Wording in readme

[<fwi...@gm...>]

On Mon, May 29, 2017 at 11:22 AM, Stefan Richthofer
<Ste...@gm...> wrote:
> Along with language and runtime compatibility with CPython
> 2.7, Jython 2.7.1 provides substantial support of the Python
Agreed, I went ahead and made that change now so I don't forget :)