jython-dev

[Jython-dev] 2.7.2 for the New Year?

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

All:

How about it? This seems like a reasonable interval since 2.7.1.

Frank/Jim: would you care to set a goal? What else ought we to have in 
that release?

I think we should mean by the answer, what we'd like to see in 2.7.2b1. 
Then we only take on fixes during beta we didn't foresee or can't avoid. 
That way, we hopefully don't stay in beta very long. I'm extrapolating a 
bit from 
https://github.com/jython/devguide/blob/jython/devcycle.rst#stages 
(cloned from CPython) but it seems a good discipline to prevent late 
de-stabilising change.

Is it perhaps as important to create a revised web site to back the 
release? (We have talked about a site we can all contribute to via GitHub.)

Also, I've been meaning to ask, the current dev tip should identify as 
"2.7.1+" (not plain "2.7.1") shouldn't it? And 2.7.2a1 then 2.7.2a1+ as 
soon as we decide we're having a 2.7.2? I think I see how this works in 
build.xml.

Jeff

-- 
Jeff Allen

Re: [Jython-dev] 2.7.2 for the New Year?

[Jim B. <jim...@py...>]

Yes! This really needs to be done. There have been some important bugs
fixed since 2.7.1, per
https://github.com/jythontools/jython/blob/master/NEWS#L6

Also agreed with 1) avoiding getting sidetracked during beta, because
that's been very expensive in terms of schedule; 2) focusing more on docs,
and especially making that sustainable/automated via github PRs and
publishing via read the docs.

The reality is that 2.7.2 is not a big release compared to what was in
2.7.1, so hopefully it's going to be also a smooth process.

Thanks for bringing this up. It's been in the back of my mind that we need
to do this. Focusing on the calendar like this gives us a good and
reasonable goal.

- Jim

On Tue, Nov 21, 2017 at 4:32 PM, Jeff Allen <ja...@fa...> wrote:

> All:
>
> How about it? This seems like a reasonable interval since 2.7.1.
>
> Frank/Jim: would you care to set a goal? What else ought we to have in
> that release?
>
> I think we should mean by the answer, what we'd like to see in 2.7.2b1.
> Then we only take on fixes during beta we didn't foresee or can't avoid.
> That way, we hopefully don't stay in beta very long. I'm extrapolating a
> bit from https://github.com/jython/devguide/blob/jython/devcycle.rst#
> stages (cloned from CPython) but it seems a good discipline to prevent
> late de-stabilising change.
>
> Is it perhaps as important to create a revised web site to back the
> release? (We have talked about a site we can all contribute to via GitHub.)
>
> Also, I've been meaning to ask, the current dev tip should identify as
> "2.7.1+" (not plain "2.7.1") shouldn't it? And 2.7.2a1 then 2.7.2a1+ as
> soon as we decide we're having a 2.7.2? I think I see how this works in
> build.xml.
>
> Jeff
>
> --
> 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
>

Re: [Jython-dev] 2.7.2 for the New Year?

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

A new year's 2.7.2 with a limited scope is definitely a great idea, as
is an updated GitHub based website. I'm on board!

-Frank

On Tue, Nov 21, 2017 at 3:32 PM, Jeff Allen <ja...@fa...> wrote:
> All:
>
> How about it? This seems like a reasonable interval since 2.7.1.
>
> Frank/Jim: would you care to set a goal? What else ought we to have in that
> release?
>
> I think we should mean by the answer, what we'd like to see in 2.7.2b1. Then
> we only take on fixes during beta we didn't foresee or can't avoid. That
> way, we hopefully don't stay in beta very long. I'm extrapolating a bit from
> https://github.com/jython/devguide/blob/jython/devcycle.rst#stages (cloned
> from CPython) but it seems a good discipline to prevent late de-stabilising
> change.
>
> Is it perhaps as important to create a revised web site to back the release?
> (We have talked about a site we can all contribute to via GitHub.)
>
> Also, I've been meaning to ask, the current dev tip should identify as
> "2.7.1+" (not plain "2.7.1") shouldn't it? And 2.7.2a1 then 2.7.2a1+ as soon
> as we decide we're having a 2.7.2? I think I see how this works in
> build.xml.
>
> Jeff
>
> --
> 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

Re: [Jython-dev] 2.7.2 for the New Year?

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

Thanks Frank. 2nd or 27th Feb, perhaps.

As you're the expert in this, can//I ask //am I doing this right (in 
build.xml, obviously):

         <!-- The current version info -->
         <property name="jython.version" value="2.7.2a1"/>
         <property name="jython.version.noplus" value="2.7.2a1"/>
         <property name="jython.major_version" value="2"/>
         <property name="jython.minor_version" value="7"/>
         <property name="jython.micro_version" value="2"/>
         <property name="jython.release_level" 
value="${PY_RELEASE_LEVEL_ALPHA}"/>
         <property name="jython.release_serial" value="1"/>

In history, I see we commit this type of change, then there's a commit 
with a tag. Am I able to push a change that adds a tag? ISTR there's a 
restriction.

When do we add the + to a version? (We seem to have forgotten so far in 
2.7.1.) Does the plus have a magical effect somewhere?

Jeff

Jeff Allen

On 22/11/2017 19:42, fwi...@gm... wrote:
> A new year's 2.7.2 with a limited scope is definitely a great idea, as
> is an updated GitHub based website. I'm on board!
>
> -Frank
>
> On Tue, Nov 21, 2017 at 3:32 PM, Jeff Allen <ja...@fa...> wrote:
>> All:
>>
>> How about it? This seems like a reasonable interval since 2.7.1.
>>
>> Frank/Jim: would you care to set a goal? What else ought we to have in that
>> release?
>>
>> I think we should mean by the answer, what we'd like to see in 2.7.2b1. Then
>> we only take on fixes during beta we didn't foresee or can't avoid. That
>> way, we hopefully don't stay in beta very long. I'm extrapolating a bit from
>> https://github.com/jython/devguide/blob/jython/devcycle.rst#stages (cloned
>> from CPython) but it seems a good discipline to prevent late de-stabilising
>> change.
>>
>> Is it perhaps as important to create a revised web site to back the release?
>> (We have talked about a site we can all contribute to via GitHub.)
>>
>> Also, I've been meaning to ask, the current dev tip should identify as
>> "2.7.1+" (not plain "2.7.1") shouldn't it? And 2.7.2a1 then 2.7.2a1+ as soon
>> as we decide we're having a 2.7.2? I think I see how this works in
>> build.xml.
>>
>> Jeff
>>
>> --
>> 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

Re: [Jython-dev] 2.7.2 for the New Year?

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

Hi Jeff,

That looks right except (as you where guessing) jython.version should be:

<property name="jython.version" value="2.7.2a1+"/>

The plus is a convention copied from CPython that I'm pretty sure
means that this is still in development and is not the tagged 2.7.2a1.
The reason we have a "noplus" version if I'm remembering correctly is
that the + doesn't work as part of a name for the maven packages.

As for tagging:

I think I'm the only one with the permissions on maven to actually
push a package, though I'm happy to share the responsibility :) -- let
me know and I will look into how you get those rights if you want
them. I think anyone can tag a release, but it probably makes sense
for the person who pushes the release to be the same as the one who
tags it.

Thanks for moving this forward!

-Frank

On Wed, Nov 22, 2017 at 1:08 PM, Jeff Allen <ja...@fa...> wrote:
> Thanks Frank. 2nd or 27th Feb, perhaps.
>
> As you're the expert in this, can I ask am I doing this right (in build.xml,
> obviously):
>
>         <!-- The current version info -->
>         <property name="jython.version" value="2.7.2a1"/>
>         <property name="jython.version.noplus" value="2.7.2a1"/>
>         <property name="jython.major_version" value="2"/>
>         <property name="jython.minor_version" value="7"/>
>         <property name="jython.micro_version" value="2"/>
>         <property name="jython.release_level"
> value="${PY_RELEASE_LEVEL_ALPHA}"/>
>         <property name="jython.release_serial" value="1"/>
>
> In history, I see we commit this type of change, then there's a commit with
> a tag. Am I able to push a change that adds a tag? ISTR there's a
> restriction.
>
> When do we add the + to a version? (We seem to have forgotten so far in
> 2.7.1.) Does the plus have a magical effect somewhere?
>
> Jeff
>
> Jeff Allen
>
> On 22/11/2017 19:42, fwi...@gm... wrote:
>
> A new year's 2.7.2 with a limited scope is definitely a great idea, as
> is an updated GitHub based website. I'm on board!
>
> -Frank
>
> On Tue, Nov 21, 2017 at 3:32 PM, Jeff Allen <ja...@fa...> wrote:
>
> All:
>
> How about it? This seems like a reasonable interval since 2.7.1.
>
> Frank/Jim: would you care to set a goal? What else ought we to have in that
> release?
>
> I think we should mean by the answer, what we'd like to see in 2.7.2b1. Then
> we only take on fixes during beta we didn't foresee or can't avoid. That
> way, we hopefully don't stay in beta very long. I'm extrapolating a bit from
> https://github.com/jython/devguide/blob/jython/devcycle.rst#stages (cloned
> from CPython) but it seems a good discipline to prevent late de-stabilising
> change.
>
> Is it perhaps as important to create a revised web site to back the release?
> (We have talked about a site we can all contribute to via GitHub.)
>
> Also, I've been meaning to ask, the current dev tip should identify as
> "2.7.1+" (not plain "2.7.1") shouldn't it? And 2.7.2a1 then 2.7.2a1+ as soon
> as we decide we're having a 2.7.2? I think I see how this works in
> build.xml.
>
> Jeff
>
> --
> 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
>
>

Re: [Jython-dev] 2.7.2 for the New Year?

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

I went with my instinct about the +. Not on the tagged version, then 
added in the next change. But maybe the next change should be to a2+, if 
+ means "approaching" rather than "beyond".

I found one reference for the CPython convention (possibly a Subversion 
convention): 
http://effbot.org/pyfaq/how-does-the-python-version-numbering-scheme-work.htm, 
but it's gone from the modern FAQ.

What we should be doing is laid out in 
https://www.python.org/dev/peps/pep-0440/, which has a lot to say about 
releases of anything in the PyPI ecosystem, but nothing about 
non-releases. We comply in the sense that 2.7.2a1 is a compliant version 
identifier.

2.7.2a1+ violates PEP 440, so it does not identify a release, which in a 
sense is what we wanted to say.

Jeff Allen

On 22/11/2017 22:17, fwi...@gm... wrote:
> Hi Jeff,
>
> That looks right except (as you where guessing) jython.version should be:
>
> <property name="jython.version" value="2.7.2a1+"/>
>
> The plus is a convention copied from CPython that I'm pretty sure
> means that this is still in development and is not the tagged 2.7.2a1.
> The reason we have a "noplus" version if I'm remembering correctly is
> that the + doesn't work as part of a name for the maven packages.
>
> As for tagging:
>
> I think I'm the only one with the permissions on maven to actually
> push a package, though I'm happy to share the responsibility :) -- let
> me know and I will look into how you get those rights if you want
> them. I think anyone can tag a release, but it probably makes sense
> for the person who pushes the release to be the same as the one who
> tags it.
>
> Thanks for moving this forward!
>
> -Frank
>
> On Wed, Nov 22, 2017 at 1:08 PM, Jeff Allen <ja...@fa...> wrote:
>> Thanks Frank. 2nd or 27th Feb, perhaps.
>>
>> As you're the expert in this, can I ask am I doing this right (in build.xml,
>> obviously):
>>
>>          <!-- The current version info -->
>>          <property name="jython.version" value="2.7.2a1"/>
>>          <property name="jython.version.noplus" value="2.7.2a1"/>
>>          <property name="jython.major_version" value="2"/>
>>          <property name="jython.minor_version" value="7"/>
>>          <property name="jython.micro_version" value="2"/>
>>          <property name="jython.release_level"
>> value="${PY_RELEASE_LEVEL_ALPHA}"/>
>>          <property name="jython.release_serial" value="1"/>
>>
>> In history, I see we commit this type of change, then there's a commit with
>> a tag. Am I able to push a change that adds a tag? ISTR there's a
>> restriction.
>>
>> When do we add the + to a version? (We seem to have forgotten so far in
>> 2.7.1.) Does the plus have a magical effect somewhere?
>>
>> Jeff
>>
>> Jeff Allen
>>
>> On 22/11/2017 19:42, fwi...@gm... wrote:
>>
>> A new year's 2.7.2 with a limited scope is definitely a great idea, as
>> is an updated GitHub based website. I'm on board!
>>
>> -Frank
>>
>> On Tue, Nov 21, 2017 at 3:32 PM, Jeff Allen <ja...@fa...> wrote:
>>
>> All:
>>
>> How about it? This seems like a reasonable interval since 2.7.1.
>>
>> Frank/Jim: would you care to set a goal? What else ought we to have in that
>> release?
>>
>> I think we should mean by the answer, what we'd like to see in 2.7.2b1. Then
>> we only take on fixes during beta we didn't foresee or can't avoid. That
>> way, we hopefully don't stay in beta very long. I'm extrapolating a bit from
>> https://github.com/jython/devguide/blob/jython/devcycle.rst#stages (cloned
>> from CPython) but it seems a good discipline to prevent late de-stabilising
>> change.
>>
>> Is it perhaps as important to create a revised web site to back the release?
>> (We have talked about a site we can all contribute to via GitHub.)
>>
>> Also, I've been meaning to ask, the current dev tip should identify as
>> "2.7.1+" (not plain "2.7.1") shouldn't it? And 2.7.2a1 then 2.7.2a1+ as soon
>> as we decide we're having a 2.7.2? I think I see how this works in
>> build.xml.
>>
>> Jeff
>>
>> --
>> 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
>>
>>

Re: [Jython-dev] 2.7.2 for the New Year?

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

Hi Jeff - some comments inline:

On Sun, Feb 25, 2018 at 12:49 AM, Jeff Allen <ja...@fa...> wrote:
> It's still the New Year :)
>
> We currently have 85 open bugs tagged Milestone 2.7.2, and about 250 others.
> (20 or so are tagged 2.7.1 or 2.7.0, but I think that's mostly a
> misunderstanding at the time they were raised.) It's hard for me to say
> which should be show-stoppers.
>
> I thought I'd at least read them all. So far I've got 2 categories: "fairly
> sure I can close" and "that's not simple".
>
> I think we should have tagged as Milestone 2.7.2 only those things we have a
> serious intention to fix by the end of 2.7.2b, and everything else
> decisively put off. Knowledgeable contributions to this process would be
> welcome.
That sounds right to me, we can put others into a 2.7.3 Milestone perhaps.

> I think (below) Frank bids a GitHub-based website as part of the 2.7.2,
> which I think is highly desirable for communication reasons.
Yes I need to look at the logistics of getting a github based website
up and running. I'll try to find some time to look into that soonish.

Thanks for looking into this and keeping the ball rolling!

-Frank

Re: [Jython-dev] 2.7.2 for the New Year?

[James M. <jam...@gm...>]

Hi All

I think the idea of having a 2.7.2 release soon is a good one. There are a
few important fixes already included since 2.7.1 especially bug 2620 which
stops the launcher working on some Windows systems. I will look through the
2.7.2 tickets and see if I can help I don't have too much free time at the
moment though. I agree that narrowing down the bugs marked with milestone
2.7.2 will allow focus on what should be worked on.

The one which I currently have in progress 2639 is almost fixed but I have
added more tests and a few are still failing so I need to fix that up but
hopefully not much more work once I get round to it.

I think having a Github based website is a great idea. The current
jython.org site gives the impression the project is abandoned. Having one
place to go where you can see the code, latest news, docs and download
releases and contribute would be a benefit, in my opinion, but it will need
some effort to get started.

James

On 25 February 2018 at 19:40, Jeff Allen <ja...@fa...> wrote:

> (The jython-dev list has taken to rejecting my mail so resending to you
> explicitly. )
>
> It's still the New Year :)
>
> We currently have 85 open bugs tagged Milestone 2.7.2, and about 250
> others. (20 or so are tagged 2.7.1 or 2.7.0, but I think that's mostly a
> misunderstanding at the time they were raised.) It's hard for me to say
> which should be show-stoppers.
>
> I thought I'd at least read them all. So far I've got 2 categories:
> "fairly sure I can close" and "that's not simple". Very early days.
>
> I think we should have tagged as Milestone 2.7.2 only those things we have
> a serious intention to fix by the end of 2.7.2b, and everything else
> decisively put off. Knowledgeable contributions to this process would be
> welcome.
>
> I think (below) Frank bids a GitHub-based website as part of the 2.7.2,
> which I think is highly desirable for communication reasons.
> Jeff
>
>
> Jeff Allen
>
> On 22/11/2017 19:42, fwi...@gm... wrote:
>
> A new year's 2.7.2 with a limited scope is definitely a great idea, as
> is an updated GitHub based website. I'm on board!
>
> -Frank
>
> On Tue, Nov 21, 2017 at 3:32 PM, Jeff Allen <ja...@fa...> <ja...@fa...> wrote:
>
> All:
>
> How about it? This seems like a reasonable interval since 2.7.1.
>
> Frank/Jim: would you care to set a goal? What else ought we to have in that
> release?
>
> I think we should mean by the answer, what we'd like to see in 2.7.2b1. Then
> we only take on fixes during beta we didn't foresee or can't avoid. That
> way, we hopefully don't stay in beta very long. I'm extrapolating a bit fromhttps://github.com/jython/devguide/blob/jython/devcycle.rst#stages (cloned
> from CPython) but it seems a good discipline to prevent late de-stabilising
> change.
>
> Is it perhaps as important to create a revised web site to back the release?
> (We have talked about a site we can all contribute to via GitHub.)
>
> Also, I've been meaning to ask, the current dev tip should identify as
> "2.7.1+" (not plain "2.7.1") shouldn't it? And 2.7.2a1 then 2.7.2a1+ as soon
> as we decide we're having a 2.7.2? I think I see how this works in
> build.xml.
>
> Jeff
>
> --
> 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>
>

Re: [Jython-dev] 2.7.2 for the New Year?

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

I'm continuing the triage of issues, slowly. Given our rate of work and 
jointly-expressed desire for a release, I find the only rational course 
is to take off nearly all the 2.7.2 tags, unless it would be harmful to 
release with that issue. (I might add some on that basis.) I'll do my 
best to follow the comments on each issue first.

I'll get this wrong many times, so if I've taken 2.7.2 off where you can 
see Jython wouldn't be viable with that issue outstanding, please argue 
it on the issue. Also, a good patch or commit is close to an irrefutable 
argument for inclusion. Anyone is free to to fix something just because 
they think it worthwhile or fun to do: we're all volunteers.

That said, we have a fair number of issues related to sockets/SSL that I 
find difficult to assess accurately and could not easily work on. If 
your skills and interest run that way, they might be good choices.

Some projects tag issues as "suitable for beginners". We don't have such 
a tag, but as I go through the issues, I find Jim has often done the 
like in a comment or given a hint towards the likely solution, which is 
useful for the rest of us.

Other thoughts in line ...

Jeff

On 26/02/2018 03:00, fwi...@gm... wrote:
> Hi Jeff - some comments inline:
>
> On Sun, Feb 25, 2018 at 12:49 AM, Jeff Allen <ja...@fa...> wrote:
>> It's still the New Year :)
>>
>> We currently have 85 open bugs tagged Milestone 2.7.2, and about 250 others.
>> (20 or so are tagged 2.7.1 or 2.7.0, but I think that's mostly a
>> misunderstanding at the time they were raised.) It's hard for me to say
>> which should be show-stoppers.
>>
>> I thought I'd at least read them all. So far I've got 2 categories: "fairly
>> sure I can close" and "that's not simple".
>>
>> I think we should have tagged as Milestone 2.7.2 only those things we have a
>> serious intention to fix by the end of 2.7.2b, and everything else
>> decisively put off. Knowledgeable contributions to this process would be
>> welcome.
> That sounds right to me, we can put others into a 2.7.3 Milestone perhaps.
No milestones are available for selection in the tracker beyond 2.7.2, 
so we can't express that idea at present. Also, I think it means very 
little to add 2.7.3 until we start to plan it. Anything not tagged is a 
candidate for 2.7.3 according to priority (or fancy). Priority and 
severity are useful at all times, I think.

A 2.7.3 milestone could be in the database ready, however. Oddly, I can 
report an error against 2.7.3 if I want, but not against 2.7.2.

>> I think (below) Frank bids a GitHub-based website as part of the 2.7.2,
>> which I think is highly desirable for communication reasons.
> Yes I need to look at the logistics of getting a github based website
> up and running. I'll try to find some time to look into that soonish.
That would be great. And we need the basic content, of course, before 
throwing the switch. I'm going to focus on the issues triage.

Jeff

Re: [Jython-dev] 2.7.2 for the New Year?

[Jim B. <jim...@py...>]

Jeff,

This makes sense to remove tags. Certainly there was optimistic estimation
of available resources on my part, based on what I was then doing — I went
from 50% (or more) availability 3 years ago, then 20% 2 years ago but
combined with a heavy part-time teaching load, to basically none at this
moment. (But I hope to have some chance to contribute by this summer!)

We have a lot of great work in 2.7.2, so it's important to get this out. My
basic feeling is that the web site cleanup, especially moving to some sort
of ReadTheDocs approach, is the big thing that needs to be done. Most
likely everything else outstanding can go into a later release.

- Jim


On Fri, Mar 2, 2018 at 9:14 AM, Jeff Allen <ja...@fa...> wrote:

> I'm continuing the triage of issues, slowly. Given our rate of work and
> jointly-expressed desire for a release, I find the only rational course is
> to take off nearly all the 2.7.2 tags, unless it would be harmful to
> release with that issue. (I might add some on that basis.) I'll do my best
> to follow the comments on each issue first.
>
> I'll get this wrong many times, so if I've taken 2.7.2 off where you can
> see Jython wouldn't be viable with that issue outstanding, please argue it
> on the issue. Also, a good patch or commit is close to an irrefutable
> argument for inclusion. Anyone is free to to fix something just because
> they think it worthwhile or fun to do: we're all volunteers.
>
> That said, we have a fair number of issues related to sockets/SSL that I
> find difficult to assess accurately and could not easily work on. If your
> skills and interest run that way, they might be good choices.
>
> Some projects tag issues as "suitable for beginners". We don't have such a
> tag, but as I go through the issues, I find Jim has often done the like in
> a comment or given a hint towards the likely solution, which is useful for
> the rest of us.
>
> Other thoughts in line ...
>
> Jeff
>
> On 26/02/2018 03:00, fwi...@gm... wrote:
>
>> Hi Jeff - some comments inline:
>>
>> On Sun, Feb 25, 2018 at 12:49 AM, Jeff Allen <ja...@fa...> wrote:
>>
>>> It's still the New Year :)
>>>
>>> We currently have 85 open bugs tagged Milestone 2.7.2, and about 250
>>> others.
>>> (20 or so are tagged 2.7.1 or 2.7.0, but I think that's mostly a
>>> misunderstanding at the time they were raised.) It's hard for me to say
>>> which should be show-stoppers.
>>>
>>> I thought I'd at least read them all. So far I've got 2 categories:
>>> "fairly
>>> sure I can close" and "that's not simple".
>>>
>>> I think we should have tagged as Milestone 2.7.2 only those things we
>>> have a
>>> serious intention to fix by the end of 2.7.2b, and everything else
>>> decisively put off. Knowledgeable contributions to this process would be
>>> welcome.
>>>
>> That sounds right to me, we can put others into a 2.7.3 Milestone perhaps.
>>
> No milestones are available for selection in the tracker beyond 2.7.2, so
> we can't express that idea at present. Also, I think it means very little
> to add 2.7.3 until we start to plan it. Anything not tagged is a candidate
> for 2.7.3 according to priority (or fancy). Priority and severity are
> useful at all times, I think.
>
> A 2.7.3 milestone could be in the database ready, however. Oddly, I can
> report an error against 2.7.3 if I want, but not against 2.7.2.
>
> I think (below) Frank bids a GitHub-based website as part of the 2.7.2,
>>> which I think is highly desirable for communication reasons.
>>>
>> Yes I need to look at the logistics of getting a github based website
>> up and running. I'll try to find some time to look into that soonish.
>>
> That would be great. And we need the basic content, of course, before
> throwing the switch. I'm going to focus on the issues triage.
>
> 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
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] 2.7.2 for the New Year?

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

I have read every open issue now on bugs.jython.org, understood the vast 
majority, commented on many of them, and investigated a few in depth. If 
it seemed to be invalid or fixed, I closed it or made it pending 
fixed/invalid/etc..

I use "pending" to mean "probably, but let's see what anyone else or 
experience tells us". 295 are open, 22 are "pending".

In a massive cull, I have taken the 2.7.2 milestone off all but 15. 
These are in the following categories:

 1. Obstacle to running Jython on Java 9. (We can't ignore that any
    longer, surely?)
 2. Obstacle to using with Gradle. (I need to understand it better -- or
    someone else does.)
 3. Actually or nearly resolved (significant recent progress, patch or
    just waiting confirmation fixed).
 4. Web site update (possible 16th issue to cover).

There is plenty of room to disagree about the choice. Also, *not* 
assigning to 2.7.2 is not a prohibition on contributing something you 
fancy doing. I assigned myself some I liked but don't think are 2.7.2 
blockers. Unfortunately, the first two could be complicated. As 
mentioned before, sockets & SSL is a recurring theme. I've not made any 
of those blockers, but it's the area where I feel it is most likely I am 
overlooking the importance of one or more issues.

I have not done a comparable sweep of GitHub on the assumption that 
anything vital has a counterpart on the official tracker.

I think we should shy away from risky change on the trunk once we tag a 
beta version (April sometime?). I have not assigned anything to 
milestone 2.7.3 because there isn't one (!) and I think we should do so 
at this stage only if we feel really strongly and are comfortable about 
our capacity. Better not to raise hopes than to dash them later.

Reading the issues was interesting, but having to keep reading instead 
of fixing them was frustrating, so I'm looking forward to doing some of 
that. Easter is coming, which will give me a few extra days. Anyone else 
able to give 2.7.2 a bit of a push?

Jeff

Jeff Allen

On 05/03/2018 09:26, Jim Baker wrote:
> Jeff,
>
> This makes sense to remove tags. Certainly there was optimistic 
> estimation of available resources on my part, based on what I was then 
> doing — I went from 50% (or more) availability 3 years ago, then 20% 2 
> years ago but combined with a heavy part-time teaching load, to 
> basically none at this moment. (But I hope to have some chance to 
> contribute by this summer!)
>
> We have a lot of great work in 2.7.2, so it's important to get this 
> out. My basic feeling is that the web site cleanup, especially moving 
> to some sort of ReadTheDocs approach, is the big thing that needs to 
> be done. Most likely everything else outstanding can go into a later 
> release.
>
> - Jim
>
>
> On Fri, Mar 2, 2018 at 9:14 AM, Jeff Allen <ja...@fa... 
> <mailto:ja...@fa...>> wrote:
>
>     I'm continuing the triage of issues, slowly. Given our rate of
>     work and jointly-expressed desire for a release, I find the only
>     rational course is to take off nearly all the 2.7.2 tags, unless
>     it would be harmful to release with that issue. (I might add some
>     on that basis.) I'll do my best to follow the comments on each
>     issue first.
>
>     I'll get this wrong many times, so if I've taken 2.7.2 off where
>     you can see Jython wouldn't be viable with that issue outstanding,
>     please argue it on the issue. Also, a good patch or commit is
>     close to an irrefutable argument for inclusion. Anyone is free to
>     to fix something just because they think it worthwhile or fun to
>     do: we're all volunteers.
>
>     That said, we have a fair number of issues related to sockets/SSL
>     that I find difficult to assess accurately and could not easily
>     work on. If your skills and interest run that way, they might be
>     good choices.
>
>     Some projects tag issues as "suitable for beginners". We don't
>     have such a tag, but as I go through the issues, I find Jim has
>     often done the like in a comment or given a hint towards the
>     likely solution, which is useful for the rest of us.
>
>     Other thoughts in line ...
>
>     Jeff
>
>     On 26/02/2018 03:00, fwi...@gm...
>     <mailto:fwi...@gm...> wrote:
>
>         Hi Jeff - some comments inline:
>
>         On Sun, Feb 25, 2018 at 12:49 AM, Jeff Allen
>         <ja...@fa... <mailto:ja...@fa...>> wrote:
>
>             It's still the New Year :)
>
>             We currently have 85 open bugs tagged Milestone 2.7.2, and
>             about 250 others.
>             (20 or so are tagged 2.7.1 or 2.7.0, but I think that's
>             mostly a
>             misunderstanding at the time they were raised.) It's hard
>             for me to say
>             which should be show-stoppers.
>
>             I thought I'd at least read them all. So far I've got 2
>             categories: "fairly
>             sure I can close" and "that's not simple".
>
>             I think we should have tagged as Milestone 2.7.2 only
>             those things we have a
>             serious intention to fix by the end of 2.7.2b, and
>             everything else
>             decisively put off. Knowledgeable contributions to this
>             process would be
>             welcome.
>
>         That sounds right to me, we can put others into a 2.7.3
>         Milestone perhaps.
>
>     No milestones are available for selection in the tracker beyond
>     2.7.2, so we can't express that idea at present. Also, I think it
>     means very little to add 2.7.3 until we start to plan it. Anything
>     not tagged is a candidate for 2.7.3 according to priority (or
>     fancy). Priority and severity are useful at all times, I think.
>
>     A 2.7.3 milestone could be in the database ready, however. Oddly,
>     I can report an error against 2.7.3 if I want, but not against 2.7.2.
>
>             I think (below) Frank bids a GitHub-based website as part
>             of the 2.7.2,
>             which I think is highly desirable for communication reasons.
>
>         Yes I need to look at the logistics of getting a github based
>         website
>         up and running. I'll try to find some time to look into that
>         soonish.
>
>     That would be great. And we need the basic content, of course,
>     before throwing the switch. I'm going to focus on the issues triage.
>
>     Jeff
>
>

Re: [Jython-dev] 2.7.2 for the New Year?

[Jim B. <jim...@py...>]

On Sat, Mar 24, 2018 at 4:58 AM, Jeff Allen <ja...@fa...> wrote:

> I have read every open issue now on bugs.jython.org, understood the vast
> majority, commented on many of them, and investigated a few in depth. If it
> seemed to be invalid or fixed, I closed it or made it pending
> fixed/invalid/etc..
>
Wow, that's an impressive amount of work to triage all these bugs!

> I use "pending" to mean "probably, but let's see what anyone else or
> experience tells us". 295 are open, 22 are "pending".
>
> In a massive cull, I have taken the 2.7.2 milestone off all but 15. These
> are in the following categories:
>
>    1. Obstacle to running Jython on Java 9. (We can't ignore that any
>    longer, surely?)
>
> Agreed, especially with the recent Java 10 GA. But presumably the same
issues apply for Java 10. The key piece here will be able to replicate what
we do with package scanning and private access. I believe there are
solutions for each. IDEs obviously have to do something like package
scanning; and private access has some options
http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/

>
>    1. Obstacle to using with Gradle. (I need to understand it better --
>    or someone else does.)
>
> re http://bugs.jython.org/issue2182 - the reasoning for this is we want
to move out of having binaries mixed with the source code tree; and make it
easier for people to reuse Jython in contemporary builds so they can pull
only our code into it and not have all of this extra crud with respect to
re-namedspaced jars.

But I don't see this as a blocker for 2.7.2

>
>    1. Actually or nearly resolved (significant recent progress, patch or
>    just waiting confirmation fixed).
>
> I would need to go through 15 of these issues, plus the 22 pending. But
for example http://bugs.jython.org/issue2230 1) we didn't get a response
from the OP; 2) Jeff's work here fixed what has to be the same bug from our
informed perspective. From a triage perspective, we have to call this
fixed. In the past I would mark this as "pending" for a week or two, then
move to fixed just to signal this to the community.

>
>    1. Web site update (possible 16th issue to cover).
>
> I would see this as the most important thing to do for the 2.7.2 release.
Of course we all love writing documentation :), but here's it's more of a
question of editing what we have in a more current format. So moving to
Read to the Docs seems like the best approach here.

There is plenty of room to disagree about the choice. Also, *not* assigning
> to 2.7.2 is not a prohibition on contributing something you fancy doing. I
> assigned myself some I liked but don't think are 2.7.2 blockers.
> Unfortunately, the first two could be complicated. As mentioned before,
> sockets & SSL is a recurring theme. I've not made any of those blockers,
> but it's the area where I feel it is most likely I am overlooking the
> importance of one or more issues.
>

I'm very skeptical of sockets/SSL blocking 2.7.2. This work proved to work
better than I ever expected for server usage; and yet because of that we
worked harder to make it even more compatible. But the reality is that we
should expect most server usage of socket code would use other Java
containers, whether they are a servlet container like Jetty or something
built directly on Netty.

> I have not done a comparable sweep of GitHub on the assumption that
> anything vital has a counterpart on the official tracker.
>
Sounds reasonable.

> I think we should shy away from risky change on the trunk once we tag a
> beta version (April sometime?). I have not assigned anything to milestone
> 2.7.3 because there isn't one (!) and I think we should do so at this stage
> only if we feel really strongly and are comfortable about our capacity.
> Better not to raise hopes than to dash them later.
>
Yes, this is very important!

> Reading the issues was interesting, but having to keep reading instead of
> fixing them was frustrating, so I'm looking forward to doing some of that.
> Easter is coming, which will give me a few extra days. Anyone else able to
> give 2.7.2 a bit of a push?
>
I'm personally very limited in what I can do until this summer at the
earliest. Maybe I can help on some of the doc stuff after Easter, but I
don't want to be on any critical path. But I do plan to be at EuroPython in
Edinburgh, since I will be nearby at that time in the UK for work reasons.

- Jim

On 05/03/2018 09:26, Jim Baker wrote:
>
> Jeff,
>
> This makes sense to remove tags. Certainly there was optimistic estimation
> of available resources on my part, based on what I was then doing — I went
> from 50% (or more) availability 3 years ago, then 20% 2 years ago but
> combined with a heavy part-time teaching load, to basically none at this
> moment. (But I hope to have some chance to contribute by this summer!)
>
> We have a lot of great work in 2.7.2, so it's important to get this out.
> My basic feeling is that the web site cleanup, especially moving to some
> sort of ReadTheDocs approach, is the big thing that needs to be done. Most
> likely everything else outstanding can go into a later release.
>
> - Jim
>
>
> On Fri, Mar 2, 2018 at 9:14 AM, Jeff Allen <ja...@fa...> wrote:
>
>> I'm continuing the triage of issues, slowly. Given our rate of work and
>> jointly-expressed desire for a release, I find the only rational course is
>> to take off nearly all the 2.7.2 tags, unless it would be harmful to
>> release with that issue. (I might add some on that basis.) I'll do my best
>> to follow the comments on each issue first.
>>
>> I'll get this wrong many times, so if I've taken 2.7.2 off where you can
>> see Jython wouldn't be viable with that issue outstanding, please argue it
>> on the issue. Also, a good patch or commit is close to an irrefutable
>> argument for inclusion. Anyone is free to to fix something just because
>> they think it worthwhile or fun to do: we're all volunteers.
>>
>> That said, we have a fair number of issues related to sockets/SSL that I
>> find difficult to assess accurately and could not easily work on. If your
>> skills and interest run that way, they might be good choices.
>>
>> Some projects tag issues as "suitable for beginners". We don't have such
>> a tag, but as I go through the issues, I find Jim has often done the like
>> in a comment or given a hint towards the likely solution, which is useful
>> for the rest of us.
>>
>> Other thoughts in line ...
>>
>> Jeff
>>
>> On 26/02/2018 03:00, fwi...@gm... wrote:
>>
>>> Hi Jeff - some comments inline:
>>>
>>> On Sun, Feb 25, 2018 at 12:49 AM, Jeff Allen <ja...@fa...> wrote:
>>>
>>>> It's still the New Year :)
>>>>
>>>> We currently have 85 open bugs tagged Milestone 2.7.2, and about 250
>>>> others.
>>>> (20 or so are tagged 2.7.1 or 2.7.0, but I think that's mostly a
>>>> misunderstanding at the time they were raised.) It's hard for me to say
>>>> which should be show-stoppers.
>>>>
>>>> I thought I'd at least read them all. So far I've got 2 categories:
>>>> "fairly
>>>> sure I can close" and "that's not simple".
>>>>
>>>> I think we should have tagged as Milestone 2.7.2 only those things we
>>>> have a
>>>> serious intention to fix by the end of 2.7.2b, and everything else
>>>> decisively put off. Knowledgeable contributions to this process would be
>>>> welcome.
>>>>
>>> That sounds right to me, we can put others into a 2.7.3 Milestone
>>> perhaps.
>>>
>> No milestones are available for selection in the tracker beyond 2.7.2, so
>> we can't express that idea at present. Also, I think it means very little
>> to add 2.7.3 until we start to plan it. Anything not tagged is a candidate
>> for 2.7.3 according to priority (or fancy). Priority and severity are
>> useful at all times, I think.
>>
>> A 2.7.3 milestone could be in the database ready, however. Oddly, I can
>> report an error against 2.7.3 if I want, but not against 2.7.2.
>>
>> I think (below) Frank bids a GitHub-based website as part of the 2.7.2,
>>>> which I think is highly desirable for communication reasons.
>>>>
>>> Yes I need to look at the logistics of getting a github based website
>>> up and running. I'll try to find some time to look into that soonish.
>>>
>> That would be great. And we need the basic content, of course, before
>> throwing the switch. I'm going to focus on the issues triage.
>>
>> Jeff
>>
>>
>
>

Re: [Jython-dev] 2.7.2 for the New Year?

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

On Sat, Mar 24, 2018 at 3:58 AM, Jeff Allen <ja...@fa...> wrote:
> I have read every open issue now on bugs.jython.org, understood the vast
> majority, commented on many of them, and investigated a few in depth. If it
> seemed to be invalid or fixed, I closed it or made it pending
> fixed/invalid/etc..
>
Thanks for all of that work!

> I use "pending" to mean "probably, but let's see what anyone else or
> experience tells us". 295 are open, 22 are "pending".
>
> In a massive cull, I have taken the 2.7.2 milestone off all but 15. These
> are in the following categories:
>
> Obstacle to running Jython on Java 9. (We can't ignore that any longer,
> surely?)
> Obstacle to using with Gradle. (I need to understand it better -- or someone
> else does.)
> Actually or nearly resolved (significant recent progress, patch or just
> waiting confirmation fixed).
> Web site update (possible 16th issue to cover).
Depending on the timeline I may be able to help on the web site, since
I've moved the website a few times before.

>
> I have not done a comparable sweep of GitHub on the assumption that anything
> vital has a counterpart on the official tracker.
>
> I think we should shy away from risky change on the trunk once we tag a beta
> version (April sometime?). I have not assigned anything to milestone 2.7.3
> because there isn't one (!) and I think we should do so at this stage only
> if we feel really strongly and are comfortable about our capacity. Better
> not to raise hopes than to dash them later.
Agreed! I can add milestones whenever we need them. If you do want the
2.7.3 let me know.

> Reading the issues was interesting, but having to keep reading instead of
> fixing them was frustrating, so I'm looking forward to doing some of that.
> Easter is coming, which will give me a few extra days. Anyone else able to
> give 2.7.2 a bit of a push?
I think I have some time during the Easter break to at least do some
planning on the website move. I'll also have a look at the tracker
tickets.

Thanks!

-Frank

Re: [Jython-dev] 2.7.2 for the New Year?

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

Happy New Year.

We didn't get 2.7.2 out in 2018, but I think it is within reach to do so 
in the first half of 2019, with a beta in (say) February.

The triage I did last Spring appears still to be valid. What looked like 
a highly focussed list proved to contain some many-headed problems. 
There are still 14 open issues in the milestone, but I would say that 
the difficult ones have yielded most of the way. We have done some work 
not in the original target because of enthusiasm or outside contributions.

Web site: not sure what the blockage is, but I think we need it to 
launch the beta release.

Gradle support: I believe "support" means we produce artefacts others 
may use in a Gradle build. Jim originally considered Gradle support to 
be essential, but has moderated that (elsewhere in this thread). My view 
is that it is highly desirable, but I don't know quite what to produce, 
although another thread in this list contains a helpful discussion. I'd 
like to make Gradle experimental in beta so we can get some experience 
and feedback.

Jeff

Jeff Allen

On 26/02/2018 03:00, fwi...@gm... wrote:
> Hi Jeff - some comments inline:
>
> On Sun, Feb 25, 2018 at 12:49 AM, Jeff Allen <ja...@fa...> wrote:
>> It's still the New Year :)
>>
>> We currently have 85 open bugs tagged Milestone 2.7.2, and about 250 others.
>> (20 or so are tagged 2.7.1 or 2.7.0, but I think that's mostly a
>> misunderstanding at the time they were raised.) It's hard for me to say
>> which should be show-stoppers.
>>
>> I thought I'd at least read them all. So far I've got 2 categories: "fairly
>> sure I can close" and "that's not simple".
>>
>> I think we should have tagged as Milestone 2.7.2 only those things we have a
>> serious intention to fix by the end of 2.7.2b, and everything else
>> decisively put off. Knowledgeable contributions to this process would be
>> welcome.
> That sounds right to me, we can put others into a 2.7.3 Milestone perhaps.
>
>> I think (below) Frank bids a GitHub-based website as part of the 2.7.2,
>> which I think is highly desirable for communication reasons.
> Yes I need to look at the logistics of getting a github based website
> up and running. I'll try to find some time to look into that soonish.
>
> Thanks for looking into this and keeping the ball rolling!
>
> -Frank
>

Re: [Jython-dev] 2.7.2 for the New Year?

[Adam B. <ada...@gm...>]

I just checked out out the head for the first time in a while and regrtest
is green for me under Windows and Java 8. Great to see.

<0.02 put in jar>

>From my (front-row?) spectator seat, I think more frequent patch releases
wouldn't hurt. It's been a fair while since 2.7.1. If the tests are green,
bugs have been fixed, and more stuff works in 2.7.2 than 2.7.1, I would
vote to ship.

If the gradle stuff is working well enough to produce a jar, it could be
included and marked experimental? I'm sure it would be useful to projects
with dependencies on jython from maven or gradle projects.

Obviously it would be good to announce the beta on the website though.

Cheers
Adam

On Wed, 2 Jan 2019 at 09:55, Jeff Allen <ja...@fa...> wrote:

> Happy New Year.
>
> We didn't get 2.7.2 out in 2018, but I think it is within reach to do so
> in the first half of 2019, with a beta in (say) February.
>
> The triage I did last Spring appears still to be valid. What looked like
> a highly focussed list proved to contain some many-headed problems.
> There are still 14 open issues in the milestone, but I would say that
> the difficult ones have yielded most of the way. We have done some work
> not in the original target because of enthusiasm or outside contributions.
>
> Web site: not sure what the blockage is, but I think we need it to
> launch the beta release.
>
> Gradle support: I believe "support" means we produce artefacts others
> may use in a Gradle build. Jim originally considered Gradle support to
> be essential, but has moderated that (elsewhere in this thread). My view
> is that it is highly desirable, but I don't know quite what to produce,
> although another thread in this list contains a helpful discussion. I'd
> like to make Gradle experimental in beta so we can get some experience
> and feedback.
>
> Jeff
>
> Jeff Allen
>
> On 26/02/2018 03:00, fwi...@gm... wrote:
> > Hi Jeff - some comments inline:
> >
> > On Sun, Feb 25, 2018 at 12:49 AM, Jeff Allen <ja...@fa...> wrote:
> >> It's still the New Year :)
> >>
> >> We currently have 85 open bugs tagged Milestone 2.7.2, and about 250
> others.
> >> (20 or so are tagged 2.7.1 or 2.7.0, but I think that's mostly a
> >> misunderstanding at the time they were raised.) It's hard for me to say
> >> which should be show-stoppers.
> >>
> >> I thought I'd at least read them all. So far I've got 2 categories:
> "fairly
> >> sure I can close" and "that's not simple".
> >>
> >> I think we should have tagged as Milestone 2.7.2 only those things we
> have a
> >> serious intention to fix by the end of 2.7.2b, and everything else
> >> decisively put off. Knowledgeable contributions to this process would be
> >> welcome.
> > That sounds right to me, we can put others into a 2.7.3 Milestone
> perhaps.
> >
> >> I think (below) Frank bids a GitHub-based website as part of the 2.7.2,
> >> which I think is highly desirable for communication reasons.
> > Yes I need to look at the logistics of getting a github based website
> > up and running. I'll try to find some time to look into that soonish.
> >
> > Thanks for looking into this and keeping the ball rolling!
> >
> > -Frank
> >
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] 2.7.2 for the New Year?

[Adam B. <ada...@gm...>]

I forgot Jeff specifically proposed gradle being experimental, so basically
take this mail as a vote for that I guess.

Cheers
Adam

On Mon, 7 Jan 2019 at 20:55, Adam Burke <ada...@gm...> wrote:

> I just checked out out the head for the first time in a while and regrtest
> is green for me under Windows and Java 8. Great to see.
>
> <0.02 put in jar>
>
> From my (front-row?) spectator seat, I think more frequent patch releases
> wouldn't hurt. It's been a fair while since 2.7.1. If the tests are green,
> bugs have been fixed, and more stuff works in 2.7.2 than 2.7.1, I would
> vote to ship.
>
> If the gradle stuff is working well enough to produce a jar, it could be
> included and marked experimental? I'm sure it would be useful to projects
> with dependencies on jython from maven or gradle projects.
>
> Obviously it would be good to announce the beta on the website though.
>
> Cheers
> Adam
>
> On Wed, 2 Jan 2019 at 09:55, Jeff Allen <ja...@fa...> wrote:
>
>> Happy New Year.
>>
>> We didn't get 2.7.2 out in 2018, but I think it is within reach to do so
>> in the first half of 2019, with a beta in (say) February.
>>
>> The triage I did last Spring appears still to be valid. What looked like
>> a highly focussed list proved to contain some many-headed problems.
>> There are still 14 open issues in the milestone, but I would say that
>> the difficult ones have yielded most of the way. We have done some work
>> not in the original target because of enthusiasm or outside contributions.
>>
>> Web site: not sure what the blockage is, but I think we need it to
>> launch the beta release.
>>
>> Gradle support: I believe "support" means we produce artefacts others
>> may use in a Gradle build. Jim originally considered Gradle support to
>> be essential, but has moderated that (elsewhere in this thread). My view
>> is that it is highly desirable, but I don't know quite what to produce,
>> although another thread in this list contains a helpful discussion. I'd
>> like to make Gradle experimental in beta so we can get some experience
>> and feedback.
>>
>> Jeff
>>
>> Jeff Allen
>>
>> On 26/02/2018 03:00, fwi...@gm... wrote:
>> > Hi Jeff - some comments inline:
>> >
>> > On Sun, Feb 25, 2018 at 12:49 AM, Jeff Allen <ja...@fa...>
>> wrote:
>> >> It's still the New Year :)
>> >>
>> >> We currently have 85 open bugs tagged Milestone 2.7.2, and about 250
>> others.
>> >> (20 or so are tagged 2.7.1 or 2.7.0, but I think that's mostly a
>> >> misunderstanding at the time they were raised.) It's hard for me to say
>> >> which should be show-stoppers.
>> >>
>> >> I thought I'd at least read them all. So far I've got 2 categories:
>> "fairly
>> >> sure I can close" and "that's not simple".
>> >>
>> >> I think we should have tagged as Milestone 2.7.2 only those things we
>> have a
>> >> serious intention to fix by the end of 2.7.2b, and everything else
>> >> decisively put off. Knowledgeable contributions to this process would
>> be
>> >> welcome.
>> > That sounds right to me, we can put others into a 2.7.3 Milestone
>> perhaps.
>> >
>> >> I think (below) Frank bids a GitHub-based website as part of the 2.7.2,
>> >> which I think is highly desirable for communication reasons.
>> > Yes I need to look at the logistics of getting a github based website
>> > up and running. I'll try to find some time to look into that soonish.
>> >
>> > Thanks for looking into this and keeping the ball rolling!
>> >
>> > -Frank
>> >
>>
>>
>> _______________________________________________
>> Jython-dev mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
>

Re: [Jython-dev] 2.7.2 for the New Year?

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

Thanks Adam. Mainly I thought we couldn't ship in such a shabby state on 
Java 9. Better now (not perfect). -- J.

Jeff Allen

On 07/01/2019 10:55, Adam Burke wrote:
> I just checked out out the head for the first time in a while and 
> regrtest is green for me under Windows and Java 8. Great to see.
>
> <0.02 put in jar>
>
> From my (front-row?) spectator seat, I think more frequent patch 
> releases wouldn't hurt. It's been a fair while since 2.7.1. If the 
> tests are green, bugs have been fixed, and more stuff works in 2.7.2 
> than 2.7.1, I would vote to ship.
>
> If the gradle stuff is working well enough to produce a jar, it could 
> be included and marked experimental? I'm sure it would be useful to 
> projects with dependencies on jython from maven or gradle projects.
>
> Obviously it would be good to announce the beta on the website though.
>
> Cheers
> Adam
>

Re: [Jython-dev] 2.7.2 for the New Year?

[Jim B. <jim...@py...>]

I agree with "better now (not perfect)"! Some more observations:

1. Java 9 is no longer supported, only Java 8 and Java 11, both of which
are under long term support.
2. Java 11 removes javax.xml.bind, which we import from DatatypeConverter;
fortunately we don't actually use! Commenting out two lines of source means
trunk builds just fine on Java 11.
3. The key change that prevented Java 9 support from running, namely
introspecting Java packages without using the rt.jar, now mostly works. In
the regrtest, it still fails with importing Pattern from java.util.regex,
not certain why; the two other imports tested in import_star_from_java.py
work fine.
4. We do have some illegal access warnings from jnr.posix in terms of
reflected fields, which we will have to look into at some point. Of course,
this is just the usual encapsulation of Java that Java 9 introduced.
5. The other failing test in test_signal when run on JDK 11 is related to
the change over to how signals are exposed.

To summarize:

     [exec] 380 tests OK.
     [exec] 2 tests skipped:
     [exec]     test_codecmaps_hk test_curses
     [exec] 2 tests failed:
     [exec]     test_import_jy test_signal
     [exec] 2 fails unexpected:
     [exec]     test_import_jy test_signal
     [exec] Result: 1

So this looks very close to me!

Lots of incredibly hard work has gone into 2.7.2, it's time to get it out
there.

- Jim

On Mon, Jan 7, 2019 at 1:19 PM Jeff Allen <ja...@fa...> wrote:

> Thanks Adam. Mainly I thought we couldn't ship in such a shabby state on
> Java 9. Better now (not perfect). -- J.
>
> Jeff Allen
>
> On 07/01/2019 10:55, Adam Burke wrote:
>
> I just checked out out the head for the first time in a while and regrtest
> is green for me under Windows and Java 8. Great to see.
>
> <0.02 put in jar>
>
> From my (front-row?) spectator seat, I think more frequent patch releases
> wouldn't hurt. It's been a fair while since 2.7.1. If the tests are green,
> bugs have been fixed, and more stuff works in 2.7.2 than 2.7.1, I would
> vote to ship.
>
> If the gradle stuff is working well enough to produce a jar, it could be
> included and marked experimental? I'm sure it would be useful to projects
> with dependencies on jython from maven or gradle projects.
>
> Obviously it would be good to announce the beta on the website though.
>
> Cheers
> Adam
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] 2.7.2 for the New Year?

[Adam B. <ada...@gm...>]

JDK 11 on Windows 10 regrtest

7 tests skipped:
    test_codecmaps_hk test_curses test_smtpnet test_socketserver
    test_subprocess test_urllib2net test_urllibnet
6 tests failed:
    test_calendar test_email test_email_renamed test_import_jy
    test_lib2to3 test_strptime
6 fails unexpected:
    test_calendar test_email test_email_renamed test_import_jy
    test_lib2to3 test_strptime
Platform:

'Java-11.0.1-OpenJDK_64-Bit_Server_VM,_11.0.1+13,_Oracle_Corporation-on-Windows_10-10.0-amd64'

This is cloned, then deleting the two redundant import statements that
break compilation, building with JDK 11, then running

dist\bin\jython.exe -m test.regrtest -e -m regrtest_memo_11_win.txt

(since I vaguely recall most of the list don't run windows)

Cheers
Adam

On Tue, 8 Jan 2019 at 16:12, Jim Baker <jim...@py...> wrote:

> I agree with "better now (not perfect)"! Some more observations:
>
> 1. Java 9 is no longer supported, only Java 8 and Java 11, both of which
> are under long term support.
> 2. Java 11 removes javax.xml.bind, which we import from DatatypeConverter;
> fortunately we don't actually use! Commenting out two lines of source means
> trunk builds just fine on Java 11.
> 3. The key change that prevented Java 9 support from running, namely
> introspecting Java packages without using the rt.jar, now mostly works. In
> the regrtest, it still fails with importing Pattern from java.util.regex,
> not certain why; the two other imports tested in import_star_from_java.py
> work fine.
> 4. We do have some illegal access warnings from jnr.posix in terms of
> reflected fields, which we will have to look into at some point. Of course,
> this is just the usual encapsulation of Java that Java 9 introduced.
> 5. The other failing test in test_signal when run on JDK 11 is related to
> the change over to how signals are exposed.
>
> To summarize:
>
>      [exec] 380 tests OK.
>      [exec] 2 tests skipped:
>      [exec]     test_codecmaps_hk test_curses
>      [exec] 2 tests failed:
>      [exec]     test_import_jy test_signal
>      [exec] 2 fails unexpected:
>      [exec]     test_import_jy test_signal
>      [exec] Result: 1
>
> So this looks very close to me!
>
> Lots of incredibly hard work has gone into 2.7.2, it's time to get it out
> there.
>
> - Jim
>
> On Mon, Jan 7, 2019 at 1:19 PM Jeff Allen <ja...@fa...> wrote:
>
>> Thanks Adam. Mainly I thought we couldn't ship in such a shabby state on
>> Java 9. Better now (not perfect). -- J.
>>
>> Jeff Allen
>>
>> On 07/01/2019 10:55, Adam Burke wrote:
>>
>> I just checked out out the head for the first time in a while and
>> regrtest is green for me under Windows and Java 8. Great to see.
>>
>> <0.02 put in jar>
>>
>> From my (front-row?) spectator seat, I think more frequent patch releases
>> wouldn't hurt. It's been a fair while since 2.7.1. If the tests are green,
>> bugs have been fixed, and more stuff works in 2.7.2 than 2.7.1, I would
>> vote to ship.
>>
>> If the gradle stuff is working well enough to produce a jar, it could be
>> included and marked experimental? I'm sure it would be useful to projects
>> with dependencies on jython from maven or gradle projects.
>>
>> Obviously it would be good to announce the beta on the website though.
>>
>> Cheers
>> Adam
>>
>> _______________________________________________
>> Jython-dev mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
>

Re: [Jython-dev] 2.7.2 for the New Year?

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

Thanks Jim.

1. It would be worth deciding whether we support Java 7. It was sensible 
a year ago, I think, especially given that ANTLR produced horrible 
(although apparently harmless) stack dumps on Java 8+: it didn't feel 
safe to build a release other than on 7, but that's now fixed. (Java 9 
and 10 went by quickly, didn't they? I suppose this moves our target :( 
to 7/8 &11.)

2. Darn, I guess I missed the import. It came and went a few times in 
the edit. Normally I let the IDE sort this out last thing, but hold off 
with old code as it creates noise in the change set. Easily fixed.

3. I have done a partial job on this, only scanning some modules, and 
intend to revisit. I do not think this explains a problem with Pattern.

4. A reflective access warning only occur if you are foolish enough to 
ask for a real fd. I regard this as unavoidable (but we now avoid doing 
it ourselves).

5. Signals: not something I understand very well at present.

Let's not forget ski8pped tests. However, each should have an issue, and 
that issue may not be in this milestone.

I wonder if Adam's extra failing tests might be to do with localisation?

Jeff Allen

On 08/01/2019 06:12, Jim Baker wrote:
> I agree with "better now (not perfect)"! Some more observations:
>
> 1. Java 9 is no longer supported, only Java 8 and Java 11, both of 
> which are under long term support.
> 2. Java 11 removes javax.xml.bind, which we import from 
> DatatypeConverter; fortunately we don't actually use! Commenting out 
> two lines of source means trunk builds just fine on Java 11.
> 3. The key change that prevented Java 9 support from running, namely 
> introspecting Java packages without using the rt.jar, now mostly 
> works. In the regrtest, it still fails with importing Pattern from 
> java.util.regex, not certain why; the two other imports tested 
> in import_star_from_java.py work fine.
> 4. We do have some illegal access warnings from jnr.posix in terms of 
> reflected fields, which we will have to look into at some point. Of 
> course, this is just the usual encapsulation of Java that Java 9 
> introduced.
> 5. The other failing test in test_signal when run on JDK 11 is related 
> to the change over to how signals are exposed.
>
> To summarize:
>
>      [exec] 380 tests OK.
>      [exec] 2 tests skipped:
>      [exec]     test_codecmaps_hk test_curses
>      [exec] 2 tests failed:
>      [exec]     test_import_jy test_signal
>      [exec] 2 fails unexpected:
>      [exec]     test_import_jy test_signal
>      [exec] Result: 1
>
> So this looks very close to me!
>
> Lots of incredibly hard work has gone into 2.7.2, it's time to get it 
> out there.
>
> - Jim
>
> On Mon, Jan 7, 2019 at 1:19 PM Jeff Allen <ja...@fa... 
> <mailto:ja...@fa...>> wrote:
>
>     Thanks Adam. Mainly I thought we couldn't ship in such a shabby
>     state on Java 9. Better now (not perfect). -- J.
>
>     Jeff Allen
>
>     On 07/01/2019 10:55, Adam Burke wrote:
>>     I just checked out out the head for the first time in a while and
>>     regrtest is green for me under Windows and Java 8. Great to see.
>>
>>     <0.02 put in jar>
>>
>>     From my (front-row?) spectator seat, I think more frequent patch
>>     releases wouldn't hurt. It's been a fair while since 2.7.1. If
>>     the tests are green, bugs have been fixed, and more stuff works
>>     in 2.7.2 than 2.7.1, I would vote to ship.
>>
>>     If the gradle stuff is working well enough to produce a jar, it
>>     could be included and marked experimental? I'm sure it would be
>>     useful to projects with dependencies on jython from maven or
>>     gradle projects.
>>
>>     Obviously it would be good to announce the beta on the website
>>     though.
>>
>>     Cheers
>>     Adam
>>
>     _______________________________________________
>     Jython-dev mailing list
>     Jyt...@li...
>     <mailto:Jyt...@li...>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] 2.7.2 for the New Year?

[James M. <jam...@gm...>]

I agree a 2.7.2 release as soon as possible would be great. Sorry I haven't
done much work on Jython since the website but hopefully have a look at the
remaining issues soon.

My opinion on Java support would be to try for 8 and 11. Is there is a
compelling reason maintain 7 support? Dropping 7 would be nice for java
syntax and might allow some issue to be looked at e.g.
http://bugs.jython.org/issue2695, on the other hand we still have 7 working
now so maybe its worth keeping for this release? Also I think we should be
careful to say which we actually support vs which work. I think making
Jython run on 7,8,9,10 and 11 is possible but saying only 8 and 11 are
officially supported makes things a bit easier going forward?

I haven't followed the Gradle discussion, so based on nothing here are my
opinions. Gradle is probably the nicest Java build system available at the
moment (i.e its what I would use given free choice). I think the real gain
would be to produce a smaller jar without the bundled dependencies (but
with a POM) so that people could integrate jython into other products more
easily where they have their own dependencies to worry about. The current
build.gradle looks really nice! I will have a play with it. A related issue
I mean to look at is OSGi support
https://github.com/jythontools/jython/issues/79 I think adding some
manifest header would be enough to make a start on this so I would like to
try and do that for this release.

Here is the current master regtest result on my system (Linux, Oracle Java
11.0.1):
     [exec] 379 tests OK.
     [exec] 2 tests skipped:
     [exec]     test_codecmaps_hk test_curses
     [exec] 3 tests failed:
     [exec]     test_import_jy test_signal test_socket
     [exec] 3 fails unexpected:
     [exec]     test_import_jy test_signal test_socket

So its pretty close.

Thanks for all the hard work already done towards 2.7.2

James

On Tue, 8 Jan 2019 at 09:19, Jeff Allen <ja...@fa...> wrote:

> Thanks Jim.
>
> 1. It would be worth deciding whether we support Java 7. It was sensible a
> year ago, I think, especially given that ANTLR produced horrible (although
> apparently harmless) stack dumps on Java 8+: it didn't feel safe to build a
> release other than on 7, but that's now fixed. (Java 9 and 10 went by
> quickly, didn't they? I suppose this moves our target :( to 7/8 &11.)
>
> 2. Darn, I guess I missed the import. It came and went a few times in the
> edit. Normally I let the IDE sort this out last thing, but hold off with
> old code as it creates noise in the change set. Easily fixed.
>
> 3. I have done a partial job on this, only scanning some modules, and
> intend to revisit. I do not think this explains a problem with Pattern.
>
> 4. A reflective access warning only occur if you are foolish enough to ask
> for a real fd. I regard this as unavoidable (but we now avoid doing it
> ourselves).
>
> 5. Signals: not something I understand very well at present.
>
> Let's not forget ski8pped tests. However, each should have an issue, and
> that issue may not be in this milestone.
>
> I wonder if Adam's extra failing tests might be to do with localisation?
> Jeff Allen
>
> On 08/01/2019 06:12, Jim Baker wrote:
>
> I agree with "better now (not perfect)"! Some more observations:
>
> 1. Java 9 is no longer supported, only Java 8 and Java 11, both of which
> are under long term support.
> 2. Java 11 removes javax.xml.bind, which we import from DatatypeConverter;
> fortunately we don't actually use! Commenting out two lines of source means
> trunk builds just fine on Java 11.
> 3. The key change that prevented Java 9 support from running, namely
> introspecting Java packages without using the rt.jar, now mostly works. In
> the regrtest, it still fails with importing Pattern from java.util.regex,
> not certain why; the two other imports tested in import_star_from_java.py
> work fine.
> 4. We do have some illegal access warnings from jnr.posix in terms of
> reflected fields, which we will have to look into at some point. Of course,
> this is just the usual encapsulation of Java that Java 9 introduced.
> 5. The other failing test in test_signal when run on JDK 11 is related to
> the change over to how signals are exposed.
>
> To summarize:
>
>      [exec] 380 tests OK.
>      [exec] 2 tests skipped:
>      [exec]     test_codecmaps_hk test_curses
>      [exec] 2 tests failed:
>      [exec]     test_import_jy test_signal
>      [exec] 2 fails unexpected:
>      [exec]     test_import_jy test_signal
>      [exec] Result: 1
>
> So this looks very close to me!
>
> Lots of incredibly hard work has gone into 2.7.2, it's time to get it out
> there.
>
> - Jim
>
> On Mon, Jan 7, 2019 at 1:19 PM Jeff Allen <ja...@fa...> wrote:
>
>> Thanks Adam. Mainly I thought we couldn't ship in such a shabby state on
>> Java 9. Better now (not perfect). -- J.
>>
>> Jeff Allen
>>
>> On 07/01/2019 10:55, Adam Burke wrote:
>>
>> I just checked out out the head for the first time in a while and
>> regrtest is green for me under Windows and Java 8. Great to see.
>>
>> <0.02 put in jar>
>>
>> From my (front-row?) spectator seat, I think more frequent patch releases
>> wouldn't hurt. It's been a fair while since 2.7.1. If the tests are green,
>> bugs have been fixed, and more stuff works in 2.7.2 than 2.7.1, I would
>> vote to ship.
>>
>> If the gradle stuff is working well enough to produce a jar, it could be
>> included and marked experimental? I'm sure it would be useful to projects
>> with dependencies on jython from maven or gradle projects.
>>
>> Obviously it would be good to announce the beta on the website though.
>>
>> Cheers
>> Adam
>>
>> _______________________________________________
>> Jython-dev mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] 2.7.2 for the New Year?

[Jim B. <jim...@py...>]

On Tue, Jan 8, 2019 at 12:41 PM James Mudd <jam...@gm...> wrote:

> I agree a 2.7.2 release as soon as possible would be great. Sorry I
> haven't done much work on Jython since the website but hopefully have a
> look at the remaining issues soon.
>

Thanks for that work on the website! Hopefully jython.org will point at
https://jython.github.io/ soon!

>
> My opinion on Java support would be to try for 8 and 11. Is there is a
> compelling reason maintain 7 support? Dropping 7 would be nice for java
> syntax and might allow some issue to be looked at e.g.
> http://bugs.jython.org/issue2695, on the other hand we still have 7
> working now so maybe its worth keeping for this release? Also I think we
> should be careful to say which we actually support vs which work. I think
> making Jython run on 7,8,9,10 and 11 is possible but saying only 8 and 11
> are officially supported makes things a bit easier going forward?
>

Agreed about dropping support for Java 7. In Jython, we have only attempted
to support Java releases that are supported for the community. (Oracle does
offer commercial support for Java 6 and Java 7, but we are not part of that
program; we don't have access to their releases.) It's really not feasible
for us to do otherwise: the ecosystem moves on.

However, I wouldn't now move to Java 8 syntax/functionality for 2.7.2, it's
obviously too late in the dev process. But for 2.7.3 and later, certainly.
We would also gain functionality useful for implementing Jython, including
MethodHandle and CallSite.

- Jim


> I haven't followed the Gradle discussion, so based on nothing here are my
> opinions. Gradle is probably the nicest Java build system available at the
> moment (i.e its what I would use given free choice). I think the real gain
> would be to produce a smaller jar without the bundled dependencies (but
> with a POM) so that people could integrate jython into other products more
> easily where they have their own dependencies to worry about. The current
> build.gradle looks really nice! I will have a play with it. A related issue
> I mean to look at is OSGi support
> https://github.com/jythontools/jython/issues/79 I think adding some
> manifest header would be enough to make a start on this so I would like to
> try and do that for this release.
>
> Here is the current master regtest result on my system (Linux, Oracle Java
> 11.0.1):
>      [exec] 379 tests OK.
>      [exec] 2 tests skipped:
>      [exec]     test_codecmaps_hk test_curses
>      [exec] 3 tests failed:
>      [exec]     test_import_jy test_signal test_socket
>      [exec] 3 fails unexpected:
>      [exec]     test_import_jy test_signal test_socket
>
> So its pretty close.
>
> Thanks for all the hard work already done towards 2.7.2
>
> James
>
> On Tue, 8 Jan 2019 at 09:19, Jeff Allen <ja...@fa...> wrote:
>
>> Thanks Jim.
>>
>> 1. It would be worth deciding whether we support Java 7. It was sensible
>> a year ago, I think, especially given that ANTLR produced horrible
>> (although apparently harmless) stack dumps on Java 8+: it didn't feel safe
>> to build a release other than on 7, but that's now fixed. (Java 9 and 10
>> went by quickly, didn't they? I suppose this moves our target :( to 7/8
>> &11.)
>>
>> 2. Darn, I guess I missed the import. It came and went a few times in the
>> edit. Normally I let the IDE sort this out last thing, but hold off with
>> old code as it creates noise in the change set. Easily fixed.
>>
>> 3. I have done a partial job on this, only scanning some modules, and
>> intend to revisit. I do not think this explains a problem with Pattern.
>>
>> 4. A reflective access warning only occur if you are foolish enough to
>> ask for a real fd. I regard this as unavoidable (but we now avoid doing it
>> ourselves).
>>
>> 5. Signals: not something I understand very well at present.
>>
>> Let's not forget ski8pped tests. However, each should have an issue, and
>> that issue may not be in this milestone.
>>
>> I wonder if Adam's extra failing tests might be to do with localisation?
>> Jeff Allen
>>
>> On 08/01/2019 06:12, Jim Baker wrote:
>>
>> I agree with "better now (not perfect)"! Some more observations:
>>
>> 1. Java 9 is no longer supported, only Java 8 and Java 11, both of which
>> are under long term support.
>> 2. Java 11 removes javax.xml.bind, which we import from
>> DatatypeConverter; fortunately we don't actually use! Commenting out two
>> lines of source means trunk builds just fine on Java 11.
>> 3. The key change that prevented Java 9 support from running, namely
>> introspecting Java packages without using the rt.jar, now mostly works. In
>> the regrtest, it still fails with importing Pattern from java.util.regex,
>> not certain why; the two other imports tested in import_star_from_java.py
>> work fine.
>> 4. We do have some illegal access warnings from jnr.posix in terms of
>> reflected fields, which we will have to look into at some point. Of course,
>> this is just the usual encapsulation of Java that Java 9 introduced.
>> 5. The other failing test in test_signal when run on JDK 11 is related to
>> the change over to how signals are exposed.
>>
>> To summarize:
>>
>>      [exec] 380 tests OK.
>>      [exec] 2 tests skipped:
>>      [exec]     test_codecmaps_hk test_curses
>>      [exec] 2 tests failed:
>>      [exec]     test_import_jy test_signal
>>      [exec] 2 fails unexpected:
>>      [exec]     test_import_jy test_signal
>>      [exec] Result: 1
>>
>> So this looks very close to me!
>>
>> Lots of incredibly hard work has gone into 2.7.2, it's time to get it out
>> there.
>>
>> - Jim
>>
>> On Mon, Jan 7, 2019 at 1:19 PM Jeff Allen <ja...@fa...> wrote:
>>
>>> Thanks Adam. Mainly I thought we couldn't ship in such a shabby state on
>>> Java 9. Better now (not perfect). -- J.
>>>
>>> Jeff Allen
>>>
>>> On 07/01/2019 10:55, Adam Burke wrote:
>>>
>>> I just checked out out the head for the first time in a while and
>>> regrtest is green for me under Windows and Java 8. Great to see.
>>>
>>> <0.02 put in jar>
>>>
>>> From my (front-row?) spectator seat, I think more frequent patch
>>> releases wouldn't hurt. It's been a fair while since 2.7.1. If the tests
>>> are green, bugs have been fixed, and more stuff works in 2.7.2 than 2.7.1,
>>> I would vote to ship.
>>>
>>> If the gradle stuff is working well enough to produce a jar, it could be
>>> included and marked experimental? I'm sure it would be useful to projects
>>> with dependencies on jython from maven or gradle projects.
>>>
>>> Obviously it would be good to announce the beta on the website though.
>>>
>>> Cheers
>>> Adam
>>>
>>> _______________________________________________
>>> Jython-dev mailing list
>>> Jyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>>
>> _______________________________________________
>> Jython-dev mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
>

Re: [Jython-dev] 2.7.2 for the New Year?

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

On Tue, Jan 8, 2019 at 1:12 PM Jim Baker <jim...@py...> wrote:
>
> On Tue, Jan 8, 2019 at 12:41 PM James Mudd <jam...@gm...> wrote:
>>
>> I agree a 2.7.2 release as soon as possible would be great. Sorry I haven't done much work on Jython since the website but hopefully have a look at the remaining issues soon.
I agree, a 2.7.2 release would be great!
>
>
> Thanks for that work on the website!
Yes, thanks!

> Hopefully jython.org will point at https://jython.github.io/ soon!
I am working on this, after reading through the github docs, I got
some information from the python infrastructure folks and will be
following up soon and making another attempt.

-Frank