[Jeremy] > I'm actually reading the whole thread, but I've only read 45% of the > messages that arrived before 2:40 p.m. :-) Don't respond to anything you see before 6:45, it's all superceded already. :-) > AB> The key thing, I think, is to keep on top of the backporting. If > AB> it slips, it's an absolute monster to catch up. > > If we are going to change anything about the way we work, this strikes > me as the most likely candidate. If we are going to continue to > maintain 2.1, then a developer who checks in a fix for some bug on the > trunk should also fix it for 2.2 and 2.1 if possible. Hm, I think 2.1 may be a lost cause, but we've done this pretty consistently for 2.2, and I strongly encourage to keep doing it. If Michael can no longer do it, I'd like to call for a new volunteer, or (if all else fails) have someone at PythonLabs take over. > Basically, we need unambigious rules about when we'll stop doing micro > releases from a particular branch. I think we should maintaince on > 2.1 and 2.2, largely because 2.2 has so much experimental stuff. > Once we get to 2.3, we can re-evaluate the situation and decide > whether we want to continue maintaining 2.1. I think 2.1 is at the point where we only need to be reactive (e.g. fix reported core dumps). The focus should be to keep 2.2 alive -- sooner or later it will gain a reputation of stability. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4