Hi Ulysses, Thanks for the detailed email. I should note that while my activity on the mailing list has been greatly reduced since May, I've always been behind the scenes guiding things as needed. If you saw my email message from a few days back, you'll see where I think I've been falling short and how I'm looking to bring the project back on track. Specifically, I know what my time constraints are right now and have been looking to get people into new roles within the project quickly. At a high level, I know how I want the project to evolve, and I'm looking to open the door to even more participation from community members to get us there. And when I say "at a high level", I mean it. There are lots of places where people add their own touches to how TG works, and I'm all for that. I don't think a BDFL should be a micromanager, and I certainly can't do everything myself.
More inline below... On Nov 17, 2006, at 10:06 AM, Ulysses Almeida wrote: > I've been working with TurboGears since june. I think its a huge > FrameWork and can be very promising. I really belive this whereas I > alredy send patchs to fix some i18n problems I've found. But in my > actual feelings the project is looking worst when comparing to june's. > Seemingly the problem is related to the lack of a BDFL (Benevolent > Dictator From Life). IMHO every software development equip needs a > DBFL, especially in OpenSource development model. Every milestone > needs to focus in one objective and needs a BDFL to guarantee that it > will not swerve. In example, since june I alredy saw TG switch the > focus from SqlObject to SqlAlchemy and from Kid to Genshi. Ok, new > technology are always cool, but if we change focus every time we see a > new technology we will never have a "so waited" 1.0 version. This is worth repeating, because we haven't actually shipped "1.0" yet. 1.0 is done. Docs and bugfixes are the name of the game, and there's a really important benefit to declaring 1.0 that I'd like to start getting ASAP: the ability to make test releases. People don't release betas of betas, so I need to get out of the 1.0b cycle quickly, so that we can start doing 1.0.1b1, etc. soon. My time lately has been diverted to other things (including a TG-related project I'm hoping to open source soon). So, TG 1.0 is *done* and it features SQLObject and Kid. This is the stack that people have been using for over a year now. The next major release of TG is going to look a bit different. The switch from Kid to Genshi is a no-brainer. Ryan Tomayko (creator of Kid) has even given his blessing to Genshi. It's mostly syntax compatible and it's entirely upside. A move to Genshi is like a move to Kid 2.0. SQLAlchemy is a more dramatic move. It's query syntax is largely what you find in SQLObject, but otherwise the package is very different. Of course, it's a superset so it could be made to look like SQLObject. But, the fact of the matter is that SQLAlchemy is superior to any ORM that I've seen. While it's always possible that something even better might appear tomorrow, I think the chances of that are pretty slim. TurboGears was a nice, productive framework a year ago. Genshi and SQLAlchemy put a level of polish and power that goes way beyond what we had. Add in a few important organizational changes to the TG code itself, and we'll end up with a version that is solidly more powerful and interoperable than TG 1.0. It's a worthy upgrade, if you ask me. I've always been a fan of having one defined way of doing things, while leaving the flexibility there if you have to do something different. TG 1.0 defines "the way": as Kid+SQLObject(+CP+MochiKit). But we already know where we're heading and it'd be silly to just ignore that. I'm not saying that the next TG "might use one of these 5 template languages as it's standard". I'm saying that Genshi is where it's going. > We will > be always throwing docs away and releasing inconsistent books (and I > think the most of us prefer to write codes than docs, so trhow docs > away really hurts). What I mean (and want to propose) is: Let's get a > focus and finalize it. And to guarantee it, some one will need to do > the BDFL hard work (Kevin?). Despite the hugeness of the changes, I'm guessing that most of our current docs will need tweaks more than anything. We'll need some entirely new docs, because we'll have some brand new capabilities. But, we won't be throwing docs away. > I think, if we reach 1.0 with good and consistent docs (even without > the best and newer componets available) we can attract more developers > to join us, and than implement newer versions with more new features > and componnets, and than.... And, with an 1.0 we can easly convince > our bosses to belive that TG is a good FrameWork and with that, be > payed to work with this wonderfull tool! ;) TG 1.0 is here, and it's documented by Rapid Web Applications with TurboGears (in addition to all of the great docs that Karl and co. are putting together). Now is the time that if you want to start working on the future of turbogears, hop over to the trunk list and let's talk!. Kevin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
