I think doing this work in a 2.6 branch makes more sense for now. All my feature branches currently target 2.5 (presumably 2.5.1) for some functionality, including one I still need to create (unicodedata). As I understand it, svnmerge doesn't solve the scenario where we need to merge between branches, although there are some tools that might help instead.

Once we move to Mercurial, that problem goes away. Since we are planning to go to hg once core Python makes this transition, that's probably when we should make what we might call "trunk" 2.6.

This transition also can involve the effort to pull core Python apart from CPython, although that might be actually 2.7...

Like Phil, right now I personally am much more interested in 2.5.x since I'd like to focus on better Java integration and performance - instead of Python compatibility! - for once.

- Jim

On Sat, Jun 13, 2009 at 5:04 PM, Frank Wierzbicki <fwierzbicki@gmail.com> wrote:
On Sat, Jun 13, 2009 at 2:18 AM, Philip Jenvey<pjenvey@underboss.org> wrote:
> On Jun 11, 2009, at 10:37 AM, Frank Wierzbicki wrote:
>> I want to be more aggressive about merging from trunk back to the 2.5
>> branch compared to how things worked for the 2.2 maintenance branch.
> I want to emphasize this, we should really try tackling some of the things
> we put off before focusing on 2.6 features. There's the obvious 2.5 bug
> fixes, but also ctypes, ideally unicodedata in Java, bz2, even cjkcodecs.
> Clamp should be of highest priority.
Maybe I should consider not starting a 2.5 maint branch just yet then.
 I do need to put a 2.6 together somewhere, but maybe I'll just do
that as a branch for now (I promised a just-enough-for-netbeans 2.6
within the next week or so)

> I think folks should be responsible for their own svnmerges -- it's your
> code, you know where it should go and how to merge it better than anyone =P
That would be quite nice, I won't stop anybody :)  -- maybe I should
reduce this to an offer of help for anyone who is a bit hazy on


Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
Jython-dev mailing list

Jim Baker