Am 28.01.2011 11:33 schrieb Pavel Strashkin:
1. I'm not sure about SF. I like Trac, it's very usefull, user-friendly and easy to use product with a close integration with SVN. Do you really need to move to SF? What the main benefits of it?
We are currently using a dedicated server that is (I believe) still provided for free by WebFaction, although we promised to move to our own server long ago. The server is also pretty old, the Trac and SVN software needs to be updated, the website setup is somewhat complex and the people who maintained it are not available any more.
So we need to move anyway, and we need to simplify things. SF is good because we do not need to care about the low-level server administration any more. Also, Mark Ramm who was the project manager for TG 2.0 and now works on TG 3 is empolyed at SF and SF is actually using TG2 so we have some connection with them anyway. SF can also host Trac and SVN so we can keep that for TG1, and at the same time they are offering Git which we want to use for TG2 and TG3 now. (One of the reasons for using Git is that Pylons/Pyramid is using it, too, so this will faciliate collaboration between the projects.) Also, we can use SF for hosting the project home page and other development tools, so we will have everything in one place.
2. What about 1.0.x and 1.1.x branches? I'm very happy to help TG, but we're still on 1.x so my patches (this one http://trac.turbogears.org/ticket/2535 still without comments) only for this branch. I believe that very soon we will migrate to 1.5 or 2.x, because we need the new cherrypy and we want to use jinja2, so i'll try to help and contribute this branches too.
I#ll continue to maintain the 1.x branches. If need be, there still will be bug and security fixes for TG 1.0 and 1.1, but the focus is now on TG 1.5 which will be released soon.
P.S. why nobody loves SqlObject? :)) To me it's better and easier that SqlAlchemy.
Well I think SQLAlchemy is more flexbile, particularly if you need to work with a given database design instead of creating one from the model classes. For instance, I think SQLObject can still not deal with composite primary keys. Also, SQLAlchemy is maintained by a very active, brilliant and friendly Gentleman, has excellent and extensive documentation and also great user support on their mailing list. For me, it's one of the really outstanding Python projects. SQLObject may be good, but I think it cannot keep up with that.
-- Christoph -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
