Hi Christoph, Hm...i want to ask the main question because i'm a bit confused now. Who is the maintainer of TG? Who is working on it? Only you?
2011/1/25 Christoph Zwerschke <[email protected]>: > Am 25.01.2011 09:23, schrieb Alice McGregor: >> As mentioned by others, wanting "best of breed" and stable are >> somewhat mutually exclusive. >> >> OTOH, my own web framework has been stable for nearly a year and a >> half at the application level, and AFIK so has TurboGears 2.0, and TG >> 1.1 for even longer. (I still have applications in production running >> various flavours of 1.x.) > > Fully agree. Things could have been organized much better. But the > problem is (again), according to my experience, the stable and > well-maintained projects have somebody behind them who feels responsible > and commited as the project "owner" and/or some kind of company backing. > This is the case for Django and Rails and also Pyramid, but > unfortunately not for TG. This is also the case for your web frameworks > since your words "my own web framework" show you feel responsible for > that. If we had somebody considering TG as his own framework, things > would a lot run better. > >> I'm ignoring, for the most part, the dichotomy here. Stability (via >> consistent API, documentation, backwards compatibility, etc.) is a >> noble goal, and a fundamentally modular and well-thought-out >> underlying design should accommodate that in -addition- to allowing >> experimentation with more bleeding-edge features. > > Fully acknowledge. I did not want to claim that this has been handled > very well by TG in the past. In fact I have expressed my displeasure in > the sometimes chaotic and erratic development and release management > several times. But I understand the reasons why things are like that and > that things will not change by complaining, but only by somebody > stepping up as a committed project manager again. > >> This is something I've been looking for for quite some time. ;) (And >> is ever more important as I continue to refine PEP 444.) > > Btw, thanks for working on that, I guess many people appretiate that. > >> My personal opinion is that a bigger (mega) project needs more rules >> compared to a smaller sized project. >> >> IMHO, everything, great and small, requires a clear structure, >> organization, and workflow ("rules") in order to be useful, >> maintainable, and enjoyable. This ranges from style guidelines (i.e. >> PEP 8) through to consistent naming of API calls, even all the way up >> to following standard programming idioms. > > Exactly. It also includes a good project development infrastructure > which also needs some work before TG can gather way again. For TG2 we're > still using the old TG1 server with an outdated cluttered Trac that's > only integrated with SVN, we don't have a test or CI server etc. > >> There was debate of absorbing Pylons into TurboGears in order to >> provide ongoing support for 2.x users. I'm unsure if any "final >> decision" was made on that, though. > > Again, I don't see a point in discussing whether we want to maintain the > Pylons code if we can't even cope with maintaining the TG code. In any > case I think that's only an option for TG2, not for a future TG3. > > Btw, this discussion should be actually held in tg-trunk, not here. > > -- 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. > > -- 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.
