From: Stefan R. <Ste...@gm...> - 2017-05-29 14:31:54
|
I really recommend that we (at least try to) merge 2.7.1 work into Jython 3 as far as and wherever possible. That means, really go back to the spot where 3 was forked from 2.7 and look at every single commit and merge it. I suppose this can be done in a semi-automated manner. Maybe it's not possible entirely with github GUI, but maybe we can save the changesets somehow. Git certainly has a way to use a changeset file as input for its merging algorithm. Ideally we would have a script that applies all changes that are automatically mergable. Every changeset that cannot be merged automatically should get a look (from its author ideally). Either it can be adjusted with reasonable effort, or it is maybe not applicable to Jython 3 for fundamental reasons. We should do this before Jython 3 and 2 diverge even more. Chances that automatic approach is vastly applicable will decrease more and more. I really doubt I can motivate myself much to work on a Jython 3 codebase that is full of issues we already solved. I'd rather much prefer to fix things that might break due to the merge process. Unfortunately I cannot help much on this process right now, because GSoC is about to launch. Will be in for Jython 3 later this year again. Best -Stefan > Gesendet: Montag, 29. Mai 2017 um 12:07 Uhr > Von: "Jeff Allen" <ja...@fa...> > An: "Jython Developers" <jyt...@li...> > Betreff: [Jython-dev] Jython 3: greenhorn questions from an old hand > > 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 > > > ------------------------------------------------------------------------------ > 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 > |