Replying to a bunch at once. I promise, your message is in here somewhere :)
On Tue, Jun 21, 2011 at 12:50 PM, John_Nowlan <[email protected]>wrote: > As has been mentioned: a clear statement of intended direction, esp. with > regards to pylons\pyramid, i.e. how tg fits in. > This one will happen later this week. Just have to make sure with other developers before announcing plans. I will say this: We have plans for 2.2, 2.3, and 2.4. Each of these is a pretty important release, and definitely not just a patch level. For TG3, we have thoughts. We'll share them later this week, but right now they are still too vague to even give a preliminary idea. The best thing we can say is this: TG is not dead. It's not even dying. It's here, and it's getting better. Only time will allow us to prove that to you, though. > - clear, up to date (i.e. remove obsolete stuff or move it > somewhere where its clearly marked as old or put it in versioned > ‘directories’ of some sort) > That's part of the process I'm going through for this book that's being written. Every single file from the current doc tree is going to be analyzed and either placed in the book or in a "dead pages" directory. Once the book is done, the old docs will be completely deprecated. - clear starting points, i.e. definitive quickstart tutorial, > definitive how do I contribute/make changes doc > Actually, that's a very good idea. I have some of those starting points at least labelled in the new book, but having the rest of them is well worth it. I'll be adding them tonight or tomorrow night (work might need my attention tonight, unfortunately). > - make it as easy to change or make comments on as possible. > Pylons originally used Moin then is/was using confluence. I’m not sure what > they found lacking in Moin, but the idea that things could be reviewed > appeals to me. Confluence (which I’m lukewarm about) has the ability but it > has never been used on the pylons site. Django had a good app (still do?) > that allowed users to comment directly on the documentation when they were > putting the book together. Very useful imho and allowed easy, easy > commenting, which was reviewed and either accepted or not. > Right now, we're using Disqus. I'm not terribly happy with it, though, since I can't seem to find a way to easily find all comments made on a given hierarchy. For instance, I want to search through http://www.turbogears.org/2.1/docs/ and see all of the comments left on any page, and I just don't see how to do it. I'm anti-wiki, personally. Getting that would be well run, well maintained, and stays fully functional in the long term is, to put it mildly, difficult. Are there any other systems anybody can recommend? I want to have this open, I just don't know what else I can do. > A few comments on the landing page: http://turbogears.org/, maybe these > have been made before? > > - Don’t have all the initial links go offsite! > I'm not sure how much we can do there. We're linking to the other sites that we're using. I'll have to think about this one. > - As an example, the ‘browser side’ link goes to > http://beta.toscawidgets.org/apache2-default/, where your presented with > an ‘It works’ page. Wtf?! Very poor. > Believe it or not, I couldn't figure this one out. I thought it was in the docs. I've just now found and corrected this problem. > - Why link to AJAX on wikipedia? Just encourages people to wander > off… > > - keep people wanting to dig deeper > > - make the last ‘points’ on the page link to deeper explanations, > i.e. – Real multi-database support, make it a link to a page that explains > that feature and has links to relevant material (i.e. sqlalchemy) > > - ‘Support for a variety of JavaScript toolkits, and new widget > system to make building ajax heavy apps easier’ > > o This is the major draw, for me, to tg. Yet it still is not > linked/explained as well as it could be > All of these points are valid. Once we get further into the docs, we'll be better equipped to address these points. And that's definitely something to do. > Finally, enough ranting on my part, as I’m not really answering your > question: re What would it take? My direct answer to that is your doing the > right thing. I was wandering away from tg, but have been encouraged by your, > Michael’s, efforts at shepherding tg (as well as the other ‘regulars’ on the > ml, you know who you are). I’m also encouraged and happy to see Alessandro > on the ml, as all cooperation is beneficial. > Well, in that case, I'm glad to be improving things enough to make people start looking at us again. Strangely enough, I don't feel like I'm doing much more than providing a focal point: Somewhere that people can look and say "Okay, it's his responsibility". I'm glad others see it as more, but I see the other developers doing quite a lot. Alessandro is working on every ticket he can get his hands on. Christoph was instrumental in making the migration work well. Diez has, I think, answered more questions (and sometimes more promptly) than me. And that list just goes on and on. > Finally (for real), the docs are one thing but the ml (and irc, etc) are > important. It is a community. Even though I am mostly an observer, I will > say that it is an important community to me. > And for me. I'm glad to be able to work on and with TG. The people here are great, and the code is a pleasure. On Tue, Jun 21, 2011 at 12:51 PM, Martin Eliasson <[email protected]>wrote: > This is an important question. I have no quick answer but have observed > that in my own TG projects, I tend to version control the project but not TG > itself so changes are seldome done. For example, I have an unreleased hack > of form validators that allows date picker widget to use dates like > 2011-06-25 but it isn't version controlled so I never came around to make a > pull request git style. This is probably all my fault. > That's a change I'd like to see, definitely. I prefer the ISO format dates, so having that publicly accessible would be a boon. > I have one small idéa. Since I don't want to code TG itself and a TG app > simultaneous on the same machine, what if there were a complete VirtualBox > machine to download and run, complete with TG set up for development with > git/hg and everything. Just add your own ssh keys and go, do your changes, > submitt changes and throw away the machine. Right now I don't have a machine > to code on, on the other hand, that's my fault too. > I'm not sure of the benefit of this, honestly. Right now, a full testing and development environment can be obtained using the following commands: virtualenv --no-site-packages ${HOME}/tg2env source ${HOME}/tg2env/bin/activate STATIC_DEPS="true" CFLAGS="-fPIC -lgcrypt" easy_install lxml git clone git://git.code.sf.net/p/turbogears2/tg2 turbogears2-tg2 cd turbogears-tg2 python setup.py develop python setup.py nosetests And that's it: You've got all your dependencies, the test cases are running, etc. On the flip side, maintaining a VirtualBox image is a cumbersome process. I guess I'll ask everybody: Is it desirable to have such an image? I'll make it if people want it. > I'm very greatfull for what you all do. I have built a scheduling web app > for our scout island using TG2 and we are using it live since last summer. > It will be released as AGPL later, hopefully this autumn, and for load > reasons I will not disclose its location at the moment. What keeps me from > releasing it is that I'm fully occupied actually using it. > Once you do release it, let us know, and we'll link to it from the website. The more the merrier, after all :) On Tue, Jun 21, 2011 at 1:48 PM, Carlos Daniel Ruvalcaba Valenzuela < [email protected]> wrote: > Documentation on how to contribute, what repositories to use, how to > send patches or pull requests, etc. > The main bits of documentation that I'm working on this week: * The 20 minute wiki * Defining the app for the book * How to contribute > I have a few patches for Jinja2 support on turbogears2, however I'm a > bit confused about what repository should I use, how do I send the > patch? (to tg-trunk? bug tracker? have my git repo online?). > What way will it be accepted and used? Via whatever method you choose to use. What way is most preferred? a pull request. You can do it on SF.net or github (I manually mirror between SF and github, though I'll be automating soon). So, whichever tools you are most comfortable with, use them. We can work with that. > There should be branches for new stuff, for example my jinja patch > could not be integrated on 2.1 and would be better for 2.2, without a > clear explanation of what to do in the mean time, that just > discourages development, should I keep my own branch then? > I'll cover that in the full docs, but a short overview: We have four main branches: master, development, next, and pu. We've stolen the model from git. master should almost never be used. When we push a release, we push all the current code onto master and tag/release from there. next is for when we've closed development on a release, and are doing final testing/cleanup before the release. development is where all active development goes. pu is for major updates that might be controversial for some reason. For instance, a major change to the object dispatching mechanism would be started there. For your patch in particular, I would expect you to branch off of development, giving it a name like 'jinja2-updates'. From there, we'll work forward towards 2.2, and try to avoid breaking the branch by way of doing periodic merges from development onto your branch. When the time comes, we'll merge your branch into development before making next and master. That's the shorter version, anyway. > It is a bit obvious that not everyone can just add code to the core > turbogears, how do we go about reviewing patches? do we have enough > core developers to guide or help newcomers on contributing to > turbogears core? > Do we have enough developers? Definitely not. That doesn't matter to me, though, for one reason: If you're wanting to contribute, I will *make* time to talk to you. I will make effort to help you do so. If you want to help, I'm not going to stand in your way. In the end, I want to grow our community so that we eventually will have enough developers that others will be able to help at least as well as I can (and maybe more so). As for the rest of the processes, I think that's going to be down to the "how to contribute" docs. > Finally turbogears is mostly a glue between many best of breed > projects that make it useful, from pylons, toscawidgets, sqlalchemy, > repoze, sprox, etc. Most of my delays when developing with turbogears > where from "external" projects, the lack of clear documentation on how > to use them on turbogears, I often end myself moving from turbogears > docs to toscawidgets or sprox site or even looking at the source code > of these projects, documentation is perhaps the most lacking aspect of > turbogears, it is tiny compared to all the features on turbogears (as > a whole), and it is poor. What we can do is encourage documentation > development, how do we write more docs? at first is not obvious you > have to checkout the docs from the repository and edit the sphix > created docs, then we get to the same issue as with source, how do I > get my changes merged back? > For a long time, I was the docs manager. We had a definitive set of usable docs for how to add docs. Those docs, after the move to git, are no longer any good. I will work on it though, and get them back up to snuff for the next release. And, for 2.2, I am working on what will become the Book for TG. It's going to take some effort and time, but they are going to get lots better. > I think there are many passionate users and developers willing to > contribute if we had a clear and simple process to get the ball going, > even if the code does not get added to mainline branch. > I'll get that for the next release. Thank you for saying it. I should have done so for 2.1.1, but I felt it was more important to show signs of life than to get the docs fully updated (especially with how much work needs to be done to them). > Documentation > Maybe we can work something like the "django book", toss a wiki, add > Actually, it's in process: https://sourceforge.net/p/turbogears2/tg2docs/ci/7e3cde47670943d60139a121e20c80fa5f1527bd/tree/book/ It's an ugly URL, but you can see that it *is* in process. > Development > Provide some guideliness to contribute, the "Extending and > Contributing" section of the docs actually says nothing about how to > contribute. > That will happen for 2.1.2 on July 20. > Open up the development a bit more, have public branches or fast track > branches to test newcomers code early and integrate code faster to > mainline. > My vision for the process was to allow anybody to fork from the main TG2 repositories, branch from the development branch, make their repo publicly accessible, and tell people about it. Is that a bad choice? -- 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.
