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
>>
>>
>
>