On 1/23/06, Dan Jacob <[EMAIL PROTECTED]> wrote: > > It seems the problems are not so much in TurboGears itself but with the > underlying components - CherryPy in particular recently (see Ian > Bicking's comment at http://blog.ianbicking.org/my-cherrypy-rant.html).
In fairness to CherryPy, the SessionDeadlock problem that Jeremy ran into has been fixed and was fixed fairly quickly once the problem was fully described. Though Jeremy didn't mention it, I know that he ran through a variety of things that made deployment trickier than I would like. That was why I mentioned deployment in my previous message on this topic. Jeremy was using svn code, so I wouldn't expect complete stability... but, I do think we need to make deployment as easy as possible. > The problem we have is that although we can control the quality of TG > code, we can't control what goes on elsewhere. For example, us poor > benighted Windows users haven't had a functioning Toolbox until > recently, all because of Kid (and that's only fixed in the SVN, not > stable Kid release). I have wanted to add proper localization support > to form validation, but that will have to wait until it's in > FormEncode(for example, it does not seem to support unicode message > strings, which means even lazy_gettext won't work for customizing > messages). Though we can't "control" what goes on elsewhere, at this point TurboGears users represent the largest segment of users for the packages (with the possible exception of MochiKit). The CherryPy people *do* care about what we want here. Ryan Tomayko does care, in spirit, about Kid... but David Stanek has really stepped up to the plate and kept the Kid project moving along. Despite the fact that we're the largest group of users of these projects, there *are* still other users. This has the disadvantage that we can't just go changing things around willy-nilly in those projects, because that might impact other users. But, the advantage is also that those other users will come up with new ideas, features and fixes that we may not have. It'd be worth getting a new thread going on FormEncode and i18n. > The question is: how can we guarantee a stable TurboGears platform even > post 1.0 (or for that matter, 2.0) if we cannot guarantee the stability > of the underlying components ? Should we enforce a "comply or die" > attitude to other projects (if you don't fix your issues, we'll go to > Quixote/Cheetah/whatever) ? I don't think that's very workable, and TG > is having a positive "rising tide lifts all boats" effect on other > projects, but still we are often hamstrung by what happens outside of > TG, something Rails and Django don't have to worry about. I'd be very surprised if we submitted a reasonable patch to any of the projects we used and didn't have it accepted. TurboGears 1.0 will likely have version requirements that constrain it to the current major release. Once a set of components is known to work together, we lock it there (with the exception of bugfix releases). Then, as new versions of components come out, we'll update TG when we're comfortable that they work together and that we know what any compatibility issues are. As Simon points out, we don't expect others to fix the things we want fixed, but we will expect that reasonable patches will be accepted. Kevin
