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 [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev |
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" <[hidden email]> > An: "Jython Developers" <[hidden email]> > 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 > [hidden email] > https://lists.sourceforge.net/lists/listinfo/jython-dev > ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev |
Maybe my perception is coloured by the work I did last, which was very
specific to Python 2, and doesn't belong in 3, but I'd dismissed any mechanical merge as impossible or inadvisable. I think each change we made to 2 will need cherry-picking on its merits, but you're right about doing it systematically. This may actually be what I spend time doing. Given the pervasive nature of the (close to 700) changes on the Jython 3 fork, it seems likely there would be constant conflict. I expect to spend a lot of time with Kdiff3. Quite understand about your GSoC commitment: don't worry, we won't go far without you. :/ Would appreciate answers to my newbie questions. Jeff Jeff Allen On 29/05/2017 15:31, Stefan Richthofer wrote: > 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" <[hidden email]> >> An: "Jython Developers" <[hidden email]> >> 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 >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > ------------------------------------------------------------------------------ > 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 > [hidden email] > https://lists.sourceforge.net/lists/listinfo/jython-dev > ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev |
In reply to this post by Jeff Allen-2
On Mon, May 29, 2017 at 3:07 AM, Jeff Allen <[hidden email]> 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 > [hidden email] > https://lists.sourceforge.net/lists/listinfo/jython-dev ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev |
In reply to this post by Jeff Allen-2
(sorry, don't know the answers to your actual questions, actually I have somewhat the same questions)
> Maybe my perception is coloured by the work I did last, which was very specific to Python 2, and doesn't belong in 3 I guess my perception is coloured by work on metaclass issues, diamond inheritance issues w.r.t. slots etc. Also unifying PyDict and PyStringMap, adding Py.newJ contructors, and plenty of other examples that I think do apply to Jython 3 as well. Porting them will be significant work, so exploring a somewhat automatic approach would be vital. It would be already a huge win if it could do 40-50% of the work. The remaining work will already be more than enough and involve plenty of cherry picking... > Gesendet: Montag, 29. Mai 2017 um 17:26 Uhr > Von: "Jeff Allen" <[hidden email]> > An: "Stefan Richthofer" <[hidden email]>, "Jython Developers" <[hidden email]> > Betreff: Re: [Jython-dev] Jython 3: greenhorn questions from an old hand > > Maybe my perception is coloured by the work I did last, which was very > specific to Python 2, and doesn't belong in 3, but I'd dismissed any > mechanical merge as impossible or inadvisable. I think each change we > made to 2 will need cherry-picking on its merits, but you're right about > doing it systematically. This may actually be what I spend time doing. > > Given the pervasive nature of the (close to 700) changes on the Jython 3 > fork, it seems likely there would be constant conflict. I expect to > spend a lot of time with Kdiff3. > > Quite understand about your GSoC commitment: don't worry, we won't go > far without you. :/ > > Would appreciate answers to my newbie questions. > > Jeff > > Jeff Allen > > On 29/05/2017 15:31, Stefan Richthofer wrote: > > 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" <[hidden email]> > >> An: "Jython Developers" <[hidden email]> > >> 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 > >> [hidden email] > >> https://lists.sourceforge.net/lists/listinfo/jython-dev > >> > > ------------------------------------------------------------------------------ > > 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 > > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/jython-dev > > > > ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev |
In reply to this post by fwierzbicki@gmail.com
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 ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev |
On Mon, May 29, 2017 at 11:22 AM, Stefan Richthofer
<[hidden email]> 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 :) ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev |
In reply to this post by Stefan Richthofer
The difficulty of such merging can be tested in a local repository, I
think. I don't have enough git knowledge to predict. Frank has answered, as I hoped, in terms that will help all budding contributors. Jeff Allen On 29/05/2017 18:35, Stefan Richthofer wrote: > (sorry, don't know the answers to your actual questions, actually I have somewhat the same questions) > >> Maybe my perception is coloured by the work I did last, which was very specific to Python 2, and doesn't belong in 3 > I guess my perception is coloured by work on metaclass issues, diamond inheritance issues w.r.t. slots etc. > Also unifying PyDict and PyStringMap, adding Py.newJ contructors, and plenty of other examples that I think do apply to Jython 3 as well. Porting them will be significant work, so exploring a somewhat automatic approach would be vital. It would be already a huge win if it could do 40-50% of the work. The remaining work will already be more than enough and involve plenty of cherry picking... > > > >> Gesendet: Montag, 29. Mai 2017 um 17:26 Uhr >> Von: "Jeff Allen" <[hidden email]> >> An: "Stefan Richthofer" <[hidden email]>, "Jython Developers" <[hidden email]> >> Betreff: Re: [Jython-dev] Jython 3: greenhorn questions from an old hand >> >> Maybe my perception is coloured by the work I did last, which was very >> specific to Python 2, and doesn't belong in 3, but I'd dismissed any >> mechanical merge as impossible or inadvisable. I think each change we >> made to 2 will need cherry-picking on its merits, but you're right about >> doing it systematically. This may actually be what I spend time doing. >> >> Given the pervasive nature of the (close to 700) changes on the Jython 3 >> fork, it seems likely there would be constant conflict. I expect to >> spend a lot of time with Kdiff3. >> >> Quite understand about your GSoC commitment: don't worry, we won't go >> far without you. :/ >> >> Would appreciate answers to my newbie questions. >> >> Jeff >> >> Jeff Allen >> >> On 29/05/2017 15:31, Stefan Richthofer wrote: >>> 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" <[hidden email]> >>>> An: "Jython Developers" <[hidden email]> >>>> 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 >>>> [hidden email] >>>> https://lists.sourceforge.net/lists/listinfo/jython-dev >>>> >>> ------------------------------------------------------------------------------ >>> 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 >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/jython-dev >>> >> ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev |
In reply to this post by fwierzbicki@gmail.com
On 29/05/2017 18:30, [hidden email] wrote:
> On Mon, May 29, 2017 at 3:07 AM, Jeff Allen <[hidden email]> 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. > 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 ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev |
Free forum by Nabble | Edit this page |