Many thanks to Raghu for maintaining the tracker.
My thoughts on moving over to the cpython tracker are
1. Yes, this is a *great* idea.
I look at the fantastic integration that the cpython folks have with mercurial and rietveld, and think that our development process would massively improve if we had the same tools. There are great benefits to be had from a an integrated development process, and it is obvious that cpython is already experiencing those benefits: it would be fantastic if we could "inherit" that by moving to the same infrastructure.
Moreover, we'd be more likely to have jython/java considerations included into the core versions of libraries if we followed an identical process, that was familiar to cpython core devs and library maintainers.
2. However, I would *not* like to see us run a split tracker. That's just a recipe for confusion and frustration. There should be only a single tracker, IMHO, for all jython issues, inclusing history: I'd hate to see us lose all of our history, there's a lot of useful information in there.
Would it really be that difficult to migrate the contents of our roundup database to theirs?
On Wed, Feb 13, 2013 at 8:40 PM, email@example.com <firstname.lastname@example.org> wrote:
A little while ago our Jython tracker maintainer Raghuram Devarakonda
retired (If you are listening, thanks for doing it for so long
Raghuram!) and I theoretically took over. I haven't done a great job
and I'm currently having trouble getting the versions updated. I'm
considering asking if the CPython folks would be OK with us using
their tracker, by just adding a "Jython 2.5" and "Jython 2.7" label in
their version area. The other option is if someone here wants to take
over maintaining our tracker if there are any takers.... I'm actually
sort of fond of the idea of sharing the tracker as I plan to merge our
our entire Lib/ area into CPython's LIb as part of 3.x.
Here is the list of justifications I plan to send:
* In the 3.x timeframe, we plan to push all of our *.py code into the
CPython standard library. I have the support of many core devs on
this, it just hasn't been done in a systematic way yet. I've already
done this for a couple of files (for example see
http://bugs.python.org/issue16886) but I plan to see that all of our
.py files get pushed as Jython moves to 3.x. Since half of Jython's
code will live in the CPython repo anyway, why not use the same
* It would be better for Jython in general if we followed CPython's
development style more closely, with code reviews etc. It would be
essential for us to do this with code that actually lives in CPython's
standard library anyway.
* The database of who has signed a contributor agreement is clear in
bugs.python.org, but is not in bugs.jython.org, and it would probably
be too much work to sync them.
* The implementation effort would be small (really just add "Jython
2.5" and "Jython 2.7" to the Versions field and later "Jython 3.4" or
whatever version we end up targeting). I also don't see a need to
migrate the data from bugs.jython.org - we could just slowly re-direct
people to http:/bugs.python.org on a bug-by-bug basis until traffic to
htttp://bugs.jython.org gets slow enough, then we could either shut it
down or leave it up read-only.
What do you folks think? I have not discussed this with current Jython
devs yet, as I'd prefer to be sure that it would be acceptable here first.
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
Jython-dev mailing list