Reasoning about this a little, unless there are fixed expectations for the quality of each successive beta release, we should base them largely on the passage of time. By "expectations" I mean you could decide e.g. that the number of test suite fails, guilty skips, or accepted bugs has to be half what it was last time, or matches some target. But I don't advocate this.

A red buildbot ought to be a blocker, although that's simply a matter of skipping enough tests. Apart from that, I advocate time-based betas to engage a community not prepared to build from source. It's nice to get a feature you care about in the next beta, but it's more important to maintain the habit of production. I believe I could argue that a period of steady bug-fixing makes a better prelude to a release than the first appearance of a shiny feature.

We believe we have reached "beta quality", hence b1 exists. Change is almost always done without regressions and we have added important features and fixes. Therefore we must be maintaining at least beta quality and must eventually cross the threshold into release candidate territory.

I'm not sure when that release candidate threshold might be reached.  I'm not aware of any neglected features (like buffer was). MBCS maybe. io is still messy. I don't think Windows is specially an issue now, as we've nearly equalised the number of test failures between that and Linux. (Sorry, I think I added one to Linux.)

I'm largely content to be guided by others on the project about what's good enough to release, but Jim's analysis strikes me as optimistic. We have quite a lot of fails and skips in the regression tests, and sometimes they represent knotty issues. On the plus side, when we fix a knotty one, we get rid of several skips at once. This is where my energy goes at the moment. Good fun if anyone wants to join in.

Jeff

On 19/03/2014 02:32, Jim Baker wrote:
Mark,

That's a great question!

Currently in my own Jython development work I'm focused on the blocker for beta 2: pip support. Jython 2.7 must have support for the standard tools in the Python ecosystem. Of these, pip - and related virtualenv and easy_install - are absolutely critical. The pip tool in turn requires the requests package, which in turn requires support for nonblocking SSL.

It's been much more involved than we hoped, but this branch is currently converging on such support: https://bitbucket.org/jimbaker/jython-socket-reboot; currently at least 2/3 of the tests in test_socket pass, beyond the fact that it supports SSL (including Start TLS) . Remaining work includes support for pseudo socket options and similar relatively minor bits & pieces. (It's at least 2/3 of ~150 tests, but more difficult to characterize than usual since most tests use threading and perhaps consequently if there's any problem, they simply freeze the overall test.) I'm hoping that this can be substantially complete by the end of the week; I certainly cannot wait until this happens because perhaps the last thing I wanted to work on when I resumed active development on Jython was SSL, but here I am doing it ;)

There is of course other important work going on, as seen in the commits and a number of outstanding pull requests, but I believe our project consensus is that this is the one blocker we have for beta 2.

Once this socket-reboot work is resolved, I believe we will want to have one more beta, focused on performance/bug fixes. This will include the following support:
  • Bug triage, especially Windows bugs
  • Regex improvements in the underlying SRE, likely using the memoization proposed by Indra Talip https://bitbucket.org/indratalip/jython
  • Use Jackson for our implementation of the json module
(Some of these could make beta 2, but they will not block it.)

Related to this, a number of us have started a separate project, jythontools (https://github.com/jythontools/), to capture integration points that in the past we would have directly put into Jython itself, such as Clamp. Keeping such work in the jythontools project helps decouple this work.

I can understand this is frustrating for our users who want to have firm dates. The problem is that Jython 2.7.0 necessarily uses a feature-based schedule, vs a time-based schedule (as seen in CPython, for example). Jython focuses on compatibility with the Python language, as defined by the CPython reference implementation; and usability as part of the overall Python ecosystem, as now defined by PyPI and tooling like pip.

Subsequent releases of 2.7.1, etc., can instead use a time-based schedule, as we move to working on performance, better Java integration, and of course bug fixes. I certainly cannot wait until we reach that milestone!

- Jim




On Tue, Mar 18, 2014 at 2:26 PM, Mark Roberts <wizzat@gmail.com> wrote:
Hey all,

I've been looking around for some information about what the status of Jython 2.7 is, and the timeline for it coming out of beta.

-Mark

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Jython-dev mailing list
Jython-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-dev




------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech


_______________________________________________
Jython-dev mailing list
Jython-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-dev