[Jython-dev] Ascent of Jython 3

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

(Starting a new thread for this.)

Stefan:

It is a good reminder that the repository in question is described as a 
"sandbox". It's largely un-reviewed work, outside the official 
repository. However, there's quite a lot of sand in the box.

What you propose sounds good to me. So the idea is a branch from Jython 
2.7.2. I am visualising this in GitHub. Do you imagine we would have 
moved 2.7 work to GitHub first? Or does the plan work while we are still 
mastered at hg.python.org and feeding a 2.7 branch that way?

I couldn't imagine the mechanics when first I considered it, but have 
more knowledge of git now. The fusing of our dev guide back into a fork 
of the CPython dev guide is perhaps a microcosm and was good training.

All the work I've done on Jython has been driven by Python regression 
tests, although the proportion of failures has always been fairly small. 
Do you think it would work to begin by adding the tests for Python 3.7 
(or maybe aim a little lower), and repeatedly throwing ourselves at that 
rock face? The tests of course would fail massively at first. Or are 
they all only useful once Jython 3 works 80%?

As when we discussed this previously, though, I'm unable to imagine an 
automated process for merging change, unless "automated" encompasses 
long hours spent with KDiff3. When you've nearly-bulk replaced PyString 
with PyUnicode, for example, how is *any* merge going to run smoothly?

Jeff


On 23/11/2017 19:01, Stefan Richthofer wrote:
> > Merging  means pulling from 2.7 to 3, I think.
> I'm actually going to try it the other way round.
> The current situation with Jython 3 concerns me a bit. It seems to
> be in a state where it is unclear how to proceed. This makes it
> somewhat discouraging to work on it. So I think we need a proper
> plan how to go on. I'd suggest the following:
> We open a new fresh Jython 3 that starts at Jython 2.7.2 release.
> Keep in mind that the Jython 3 repository is actually a *sandbox*
> so far. We merge every commit done to Jython 3 sandbox since it
> was forked from 2.7, (hopefully mainly via automatic merge
> mechanism). This is the ideal opportunity to triage the issue
> with broken Windows support and to review Isaiahs work. While
> he did a lot great work on Jython 3 we must keep in mind that it
> has been hardly reviewed so far.
> I hope we can end up with a workable Jython 3 containing all the
> bugfixes and improvements that were added in Jython 2.7.1 and 2.
> Problematic commits can be sorted out for later additional review.
> Regarding some aspects I propose to directly target Python 3.7, e.g.
> bytecode level and language syntax. Going through intermediate
> versions would be multiple work here.
> Besides this merging work we will need a real roadmap that states
> all the milestones and steps required for a Jython 3 release. Who
> of us knows Python well enough to put this together? Jim? Frank?
> After merging is done we need a clear policy about backporting etc.
> I'd suggest to focus on Jython 3 then and only backport crucial or
> cherry-picked bugfixed to 2.7 branch.
> In the sprint I'll start an inofficial experimental Jython 3 to work 
> on merging.
> This can maybe form the basis for an official non-sandbox Jython 3.
> Thoughts?
> -Stefan