On Thu, Feb 17, 2011 at 2:13 AM, Christoph Zwerschke <[email protected]> wrote:
> Right, documentation is also important for me. Btw, don't forget I've > already worked on the layout (https://bitbucket.org/cito/tg-docs-21) so we > can start from there and concentrate on the content. > So, next up on my list of "How to make friends and influence people": That layout might not even be able to work. One of the things that's been bothering me about the docs is that, no matter what we do, it still looks more cluttered than it should be. For the docs, I'm starting to think that, to some degree, a major rewrite is required. What I'm leaning towards is using the .rst files to produce an epub, a PDF, and the HTML. The end goal of this is to provide something that flows more like a traditional book (and can even be published on lulu). The layout, very likely, can be used, though some reorg may be required. Not sure yet. You worked hard on it, though, and I am going to try very hard to make sure that work gets used as much as possible. I just don't know, right now, how much can be brought in with the ideas I've got running around. Again, though, I'm putting the cart before the horse. We've not even opened up the 2.2 work, and I'm talking about it. I need to stop that. > flow.io is not a complicated tool, you can use it intuitively without > learning efforts. And open source projects can use it for free. > So, what's the difference between using Trac tasks and flow.io? Especially if we throw in something like a gantt chart plugin? (I have seen that one, even used it, so I know it exists and does well). Especially since people can be on Trac, take tasks, etc. I promise, I'm not trying to be a jerk. I just want to understand why we should use tool A over tool B, and have a concrete reason to do so. On Thu, Feb 17, 2011 at 2:44 AM, Christoph Zwerschke <[email protected]> wrote: > Ok, that obviously needs clarification: www.turbogears.org is our old > server where all of the components (os, python, svn, trac, moinmoin wiki > etc.) are outdated now. The server had been granted by Webfaction a long > time ago, but actually only as a temporary solution, we're really drawing on > their generosity already and promised to move for a long time already. *We > really shouldn't touch that server any more*. The plan had been to move to > Florent's server but it was never realized since everybody was busy. Later > SF came up as an alternative since Mark is working there and since they also > use TG2 so we have some connections anyway. But Florent's server is still > interesting at least for the CI stuff, and maybe also for bug tracking, at > least until SF offers a more viable solution. > Okay, this tells me that we need to complete a migration away from the current server ASAP. Florent: Are you around? Can we switch www.turbogears.org to point to your server? Or should I start renting a VPS? Note: I do *not* mind renting a VPS. The costs are minimal, and it's easy enough to maintain or even transfer. Let me know what you want to see, and I'll make it happen. If you need my ssh public key, let me know and I'll get it over to you. > I also thought of writing a more realistic, sophisticated reference TG app > that could be used as base for the benchmark and functional tests and also > serve as demo app for new users. That would be better than only using a > hello world or quickstarted project to test TG performance. > > But of course, the tests should also quickstart apps with different options > and test these. I.e. we should not only test tg, but also tgdevtools. I > think currently tgdevtools has no automated tests. > I can get behind this idea as well. As for tg.devtools, I wasn't explicit enough, but I want to have that package fully and automatically tested as well. We need it just to help restore credibility in the web development community. On Thu, Feb 17, 2011 at 5:29 AM, Alessandro Molina < [email protected]> wrote: > Suppose you have just released 2.1 and you are now working on 2.2, > you think that the 2.2 is stable and merge back your development > branch in the master. In the mean time you discover that there is a > huge bug on 2.1 and you really need to release a 2.1.1, how do you > plan to do that without also realeasing the just merged in changes of > the 2.2? > Why would this set of commands not work? # on development branch git tag -a v2.1 git checkout master git merge v2.1 git checkout -b 2.2.new.feature development # complete whatever set of commits git commit -a -m "work is done!" git checkout -b 2.1.security-fix v2.1 # do the work git commit -a -m "2.1 security fix is done!" git tag -a v2.1.1 git checkout master git merge v2.1.1 git checkout 2.2.new.feature.development git merge master # work gets done git commit -a -m "2.2 ready to release!" git tag -a v2.2 git checkout master git merge v2.2 git checkout -b 2.1.sf2 v2.1.1 # work away git commit -a -m "v2.1.2 ready to roll" git tag -a v2.1.2 git checkout master git merge v2.1.2 git checkout v2.2 # work continues on 2.2 Now, why would that fail or be overly difficult to manage? > I'm really interested in a comparison of the two branching policies as > it is indeed useful also for my own projects to understand which is > the best one :D > For the best discussion of branching policies in git that I've seen yet, check out http://www.progit.org/book/ . I think I found my info in chapter 3, though am not positive. -- Michael J. Pedersen My IM IDs: Jabber/[email protected], ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/[email protected] -- You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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-trunk?hl=en.
