First, an apology. The past several weeks have been hell at work. If you want the full details, email me off the list and I'll share. I don't want to burden the whole list with it, though.
Now, I'm getting back to my regular replies and participation. On Thu, Jun 30, 2011 at 5:19 AM, werner <[email protected]> wrote: > On 06/30/2011 04:23 AM, Michael Pedersen wrote: > ... > > We've also initiated a monthly release process. The release will occur >> each month on the first Wednesday on or after the 15th of the month. >> >> Can you please clarify what release will be made monthly, i.e. you > mention 2.2, 2.3 and 2.4 will they be out in July, August, September > respectively or are the monthly ones minor, e.g. 2.2.1, 2.2.2 etc? > What will happen monthly (well, assuming life doesn't send me for a major loop like it did for July) is a ready for release state for the current code. Basically, we're going to keep frequent releases happening. When we reach the appropriate milestone, we'll release it. For instance, as of right now, we're looking to release 2.1.2. There's some outstanding docs changes that have to happen (and are blocking the release). Once those are done, I'll go through the release process that's outlined here: https://sourceforge.net/p/turbogears2/tg2docs/ci/7e3cde47670943d60139a121e20c80fa5f1527bd/tree/book/appendices/preprelease.rst(sorry for the long URL). Each release on the path is another step towards 2.4 (the furthest defined milestone, currently). When we have everything matching our goals for 2.2, we'll be releasing 2.2. Until then, we'll be releasing 2.1.x improvements which get us closer to 2.2. Similar will happen on the path to 2.3 and 2.4. > I assume it is the later in which case is there some rough release time > defined for 2.3 and 2.4. > I don't have a useful time frame. I'd like to see 2.2 out this year, but I don't know that it's possible. 2.3 should be a very short release cycle (if we let it take six months, I think we're spending a long time, since it's so focused). 2.4, though, could be a while to reach, as we have a great many extensions to put together for it. Hopefully, people will step up and help us out with all of it. If they don't, well, this roadmap is a long term one. If they do, we'll complete 2.4 sooner. On Thu, Jun 30, 2011 at 7:45 AM, Mengu <[email protected]> wrote: > i had some concerns regarding TurboGears however after i see you, > alessandro, diez and chris having your heart in it made me believe > that it's not going anywhere and you will improve it a lot. > performance is the most important feature of a web framework. this > will be the big one of the reasons people would use turbogears. maybe > you will do this with refactoring some code maybe with removing some > layers in a dispatch of a request. > Everybody has their own "most important feature" in a web framework. For some, performance is everything. I'll point out this post I wrote: http://codersbuffet.blogspot.com/2010/07/turbogears-and-amazon-ec2-benchmarking.htmland state that performance is rarely the most important factor. That's not to say it doesn't happen, and not to say that we shouldn't focus on making TG ever faster, but performance is not my personal biggest feature. My biggest feature is actually two-fold: Correctness and comprehensibility. It has to be understandable (and TG is the first framework I've ever used that actually managed to make sense to me), and it has to be correct. That's why I'm so gung ho about documentation and CI/unit testing. We need both of those to validate what we're telling people. > the decision on moving on top of pyramid from pylons is a wise > decision. pylons is no more so why rely on it or maintain it while we > have already a huge one to maintain as pylons is huge as well. from > what you've written i suppose orion is not going to happen. having > turbogears and orion was not good at all as the community was going to > split. there's no good in that. > Pylons is not receiving updates. That does not mean it is no more. It's still available. It still works. We just have to be aware that we're going to have to change at some point. When that change will occur, and how, seems a little up in the air right now. We'll see what the future holds when it gets here. > 1) code side > - making it perform way much better. > - much more nice and clean docs and api docs. > - docs should be clear as hell, not complicated, not too long. > I'm working on making a whole book for the docs, but one that will be usable as both a "read from start to finish" and a reference later on. I think that, with all of that rolled up, it will work nicely as a base for our docs for a long time. 2) marketing side > - screencasts. screencasts are very important. > - making it clear that turbogears can scale very well and it can be > adopted for any kind of web application. > - we should adapt it at our workplace and make our friends use it. > - we should let people know about turbogears in our local python meet- > ups. (i'm gonna do that next month.) > - using reddit/hackernews for status updates, release informations, > doc updates, new features. > I'm still learning how to advertise our stuff. The past few weeks is a noticeable setback, but one that I think we can recover from. Even though I wasn't able to ad much, Alessandro and Christoph *did*. We need to publicize it more, and I'm not so great at that, not yet. I'll be working on learning it once we get another couple releases under our belt, and can show some consistent momentum. On Thu, Jun 30, 2011 at 3:30 PM, Christoph Zwerschke <[email protected]> wrote: > Agreed, and one of the first things we need to do is write a benchmark > suite to monitoring the performance as we continue to develop TG. But > anyway, I do not think performance is really such a big issue for the > majority of us, and Chris Perkins has already worked on the performance in > 2.1. Where actually do you perceive performance issues? I'm not going to stop anybody from developing that performance test suite. I'm not going to focus on it myself until 2.2 is out the door, though. It matters, but until we're focused on performance (which is the point of the 2.3 release), my only major thing is to avoid major regression in speed. Right. If we make the docs too exhaustive, this may also slow down the > development because we must always adapt the docs. I already see this > happening with Pyramid which has really extensive docs. Crisp, concise docs > are what we need for TurboGears. And we don't need to document parts which > are already document very well, like SQLAlchemy. Just some introductory > words, links to the original docs, and short explanation of the TG > integration and usage. > One of the pieces I'm trying to work out how to do is to make every single code snippet that appears in the book into something completely self-contained and unit-testable. That way we can automatically test everything, and know what works without even trying. And fix things more easily as time goes on. On Thu, Jun 30, 2011 at 7:30 PM, Craig Small <[email protected]> wrote: > > SQLAlchemy. Just some introductory words, links to the original > > docs, and short explanation of the TG integration and usage. > The TG integration part is important. I have quite often looked at the > SQLAlchemy docs and thought "that is exactly what I want" and then > struggled a little to see what is the right way to do it in TG. > > Even "yes just like they do at link ..." sometimes helps, if it is true. > These are definitely areas I'm looking to address. With this next release, I'll be able to show off the beginnings of the book finally, rendered in HTML (and, eventually, epub and PDF), so you can all see what I'm thinking in much more detail. It'll make sense, and be much more useful than what we have now. -- Michael J. Pedersen My IM IDs: Jabber/[email protected], AIM/pedermj022171 Yahoo/pedermj2002, MSN/[email protected] My LinkedIn Profile: http://www.linkedin.com/in/michaeljpedersen Twitter: pedersentg -- 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.
