[Python-Dev] Re: Stability and change (original) (raw)
Guido van Rossum guido@python.org
Mon, 08 Apr 2002 18:40:01 -0400
- Previous message: [Python-Dev] Re: Stability and change
- Next message: [Python-Dev] Re: Stability and change
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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/)
- Previous message: [Python-Dev] Re: Stability and change
- Next message: [Python-Dev] Re: Stability and change
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]