|
|
|
|
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
|
|
|
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 :)
------------------------------------------------------------------------------
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
|
|
|
(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
|
|
|
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.
>
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/1853There 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
|
|
Locked
