On Nov 11, 4:59 pm, Mark Ramm <[email protected]> wrote: > There's the low level, fast, flexible, powerful framework that makes > very few assumptions, and maximizes flexibility. > > But then there's another related project that configures all of that > in a standard way, includes a lot more "batteries" and works to > provide lots of opt in options to the users of Pyramid layer, and lots > of defaults to this higher layer. > > If we go through with a merger I expect that the TurboGears > development community is going to be much more interested and much > more active on this second layer. Which is natural because it's a > reasonable outgrowth of the TurboGears philosophy.
There's another aspect as well, which I think several people brought up very clearly. No one wants to be abandoned "again" for the "next best thing". Part of the reason I think this happened is that despite TG choosing different best of breed components, and increasing the user-base, the developer base very frequently did not increase in any noticeable fashion. Some one-off patches perhaps, and that was about it. As such, if the chosen golden project that was best of breed failed to keep up, it was in danger of no longer being the best just a year or so later. That's kind of a bummer really. Already with Pyramid, I'm trying to avoid that, because for Pylons users, they'll be used to using Mako and SQLAlchemy. I want to ensure these two tools *stay* best of breed for the choice of ORM and the choice of non-XML template language. So I'm talking with Mike Bayer, because I want to ensure that SQLAlchemy/Mako have the support/help needed to keep them on top. Once something is chosen as best of breed, if enough developers hop on board, it should be pretty dang hard to de-thrown it. If Kid had a huge dev base early on, I think Genshi might not have even been necessary. So ensuring that the 'chosen tools' get the support they need feels like a very critical aspect to me. If TG merges, I'd like to ensure that with the developers that encompasses, every part of the "full stack" has sufficient resources to ensure there is no further hopping between core components. That the "best of breed" *stays* the best option, and that if something else starts to surpass it... well, there'll be enough resources available so that we can catch up. Changing projects perpetually is clearly not maintainable. I know some people were worried about other projects being gobbled by "The Pylons Project", but really, given the code/test/doc requirements necessary to be part of the Pylons Project I can't see any reason anyone should be anything other than thrilled that a project is accepted to be managed under these requirements. Cheers, Ben -- 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.
