Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Thu, Feb 17, 2011 at 5:50 PM, Michael Pedersen m.peder...@icelus.org wrote: I'll get myself logged into it tonight and check it out. I'm not going to promise anything. I will say that it looks promising, though. Then again, github looks promising, too. Part of me wonders if we might not be better off with github vs SF, too. Some of what they offer looks amazing in comparison. I'm still holding off on finalizing migration choices until this weekend. Hopefully Florent will speak up and/or we'll find the migration docs up on SF.net. Something will happen this weekend, though. I just don't know what. Sorry guys I did not monitor closely this list... my server is this one: 91.121.85.25 it responds as: beta.turbogears.org (this is a TG2 CMS) gsoc.turbogears.org (a TG2 application that a GSOC student prepared for easy HG + trac integration into a TG2 application. This one could maybe be shutdown) pypi.turbogears.org which is serving the recent releases of ToscaWidgets if not the recent one of TG... This one is really important because it is WAY better than mainting the index manually on the old server as we did for TG1 buildbot.turbogears.org (this one badly needs work... or I could replace it with a Jenkins instance... let's discuss this) All these are live TG applications running under supervision of a supervisord that does its job quite well (I did not have to connect to the server in months to restart an application) and pypi is running since 507 days whereas beta.turbogears.org as restarted 72 days ago (as exemples)... Then we also host toscawidgets.org and the tosca dvcs I can create accounts for Michael and Christoph if they want... We'll discuss the details in private (ssh keys...) The idea behind the server was to have a TG2 application running our website on it. And I even finance Jon so that he could write tgext.pages which serves the purpose... As you can see this was done quite successfully on the technical side of things... But when it came to find people to actually put content in the CMS we were quite alone. This was one of the reason we lost heart and stopped this project. I must note that at the same time some people who are no more around wanted to launch another TG2 based CMS. This did not help getting steam into the project. But since those people are no more interested in TG2 it may be interesting to get back to work on pages... As I said above we wanted a TG2 showcase and we wanted flexibility. I think that some of the applications that we have on this server can still be usefull. Ha! Last but not least, this is not a VPS but a dedicated server with quite some horse power :) Regards, Florent PS: my goal is not to keep running (and paying) for this server if we don't need it, but my point is that I pay for this server since 2 years and I can continue to pay for it for 3/4 more years without issues if we need it (even more if we want) -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 22.02.2011 11:34, schrieb Florent Aide: As I said above we wanted a TG2 showcase and we wanted flexibility. I think that some of the applications that we have on this server can still be usefull. Thanks, Florent. I think we should follow that route, we already wanted to do that a long time ago and hopefully now we have enough steam again to make it happen. I preferred SF, but it seems the beta forge (Allura) is not yet mature enough. We can of course re-evaluate that option at a later time, if we don't create a too sophisticated site that will be difficult to migrate elsewhere. Concerning the bug tracker, I vote for using the latest stable version of Trac, but split up in subprojects for TG1 and TG2. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
[tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Hi, On Feb 16, 2:12 pm, Christophe de Vienne cdevie...@gmail.com wrote: Le 16/02/2011 14:01, Christoph Zwerschke a crit : Am 16.02.2011 12:44, schrieb Christophe de Vienne: What about usinghttp://www.shiningpanda.com(or maybe some other equivalent service) ? shiningpanda looks interesting, but is not yet available as it seems. Indeed. It might be interesting to contact them though. Do anybody knows some equivalent service ? Thanks for thinking to Shining Panda. We're still developing our hosted continuous integration service for Python, but we'll step in beta by the end of february... let's say early march to be sure. We'd be happy to contribute to TG's continuous integration architecture by providing some free slots on our service. Is there someone I can contact on this topic as soon as we get the invitations for beta? Olivier Mansion, from Shining Panda team -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Thu, Feb 17, 2011 at 2:34 PM, Olivier Mansion olivier.mans...@gmail.comwrote: We're still developing our hosted continuous integration service for Python, but we'll step in beta by the end of february... let's say early march to be sure. We'd be happy to contribute to TG's continuous integration architecture by providing some free slots on our service. Is there someone I can contact on this topic as soon as we get the invitations for beta? Please feel free to contact me. I know that Christoph will be interested, as well as Mark Ramm. Any of the three of us will be able to get the ball rolling. Cris Perkins will likely be interested as well, though he's temporarily on hiatus (hopefully retuning very soon now). -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Thu, Feb 17, 2011 at 4:48 AM, Michael Pedersen m.peder...@icelus.org wrote: On Wed, Feb 16, 2011 at 6:50 AM, Alessandro Molina alessandro.mol...@gmail.com wrote: Stable code related to the in development version or code of stable releases? As I think that it is usually better to have development code on master and stable releases on their own branches as it makes easier to release patches and fixes for that specific release. Well, what I'm reading makes me think that the common/accepted practice for git is to have the master branch be the nothing happens here branch. Basically, whenever a development cycle is closed, the tag gets applied, everything gets migrated to master, and the development branch picks up new topic branches from there. This seems to have an advantage that all code (security fixes, especially) will eventually find its way to the master HEAD, or it's not fully integrated, and there's no question about it. Having a branch for all 2.1 code would allow a security fix to be applied only to 2.1, and never applied to master, and that would be (almost guaranteed) wrong. I'm open to hearing why my understanding is wrong, though. I'm not a git master, and am willing to be shown a better path. Indeed it is the most common behavior among git users, but I find that it makes harder to maintain the previous releases. Let me make an example: 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? While using a branch for each stable release has the disadvantage of having to pay attention to pushing a bugfix to each version where it is important it makes easier to maintain the previous releases. I can provide as an example a project that I maintain and that uses git: http://cgit.lscube.org/cgit.cgi/flux/ As you can see it has all the stable releases both tagged and branched (1.0 and 1.1), experimental changes on their own branch (pseudostream and test-autotools) while the development next release preparation branch is the master. I just found myself most comfortable with this structure for previous versions management. The only disadvantage that it has is that users might tend to clone the unstable branch if you don't specifically provide the clone urls of the current stable branch. 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 -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Thu, Feb 17, 2011 at 2:13 AM, Christoph Zwerschke c...@online.de 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 c...@online.de 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 alessandro.mol...@gmail.com 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
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 17.02.2011 16:18 schrieb Michael Pedersen: So, what's the difference between using Trac tasks and flow.io http://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 would use flow.io for coordinating the general project management related tasks and workflow and Trac for keeping track of concrete, detailed development tasks directly related to the code. The advantage of flow.io is that you see who is working on what at the moment and get a nice overview of what has been done recently and what needs to be done next. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
I'll get myself logged into it tonight and check it out. I'm not going to promise anything. I will say that it looks promising, though. Then again, github looks promising, too. Part of me wonders if we might not be better off with github vs SF, too. Some of what they offer looks amazing in comparison. I'm still holding off on finalizing migration choices until this weekend. Hopefully Florent will speak up and/or we'll find the migration docs up on SF.net. Something will happen this weekend, though. I just don't know what. On Thu, Feb 17, 2011 at 11:30 AM, Christoph Zwerschke c...@online.dewrote: Am 17.02.2011 16:18 schrieb Michael Pedersen: So, what's the difference between using Trac tasks and flow.io http://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 would use flow.io for coordinating the general project management related tasks and workflow and Trac for keeping track of concrete, detailed development tasks directly related to the code. The advantage of flow.io is that you see who is working on what at the moment and get a nice overview of what has been done recently and what needs to be done next. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 17.02.2011 17:50 schrieb Michael Pedersen: I'll get myself logged into it tonight and check it out. I'm not going to promise anything. I will say that it looks promising, though. Then again, github looks promising, too. Part of me wonders if we might not be better off with github vs SF, too. Some of what they offer looks amazing in comparison. Concerning flow.io please don't misundertand me, I don't propose it as an alternative bug tracker, just as an additional tool for handling the high level management tasks which are not directly related to the code and relatively few compared to the number of trac tickets. And yes, github is not bad, but I think the bugtracker is also their weak point. I'm currently busy but also want to evaluate the SF hosted trac option this weekend, so please wait until I could have a look before making any drastic moves. Also, maybe you can talk with the SF support team via IRC (#sourceforge at freenode) regarding the forge tracker documentation. They are usually very responsive and helpful. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Thu, Feb 17, 2011 at 4:18 PM, Michael Pedersen m.peder...@icelus.org wrote: 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. If hosting for TG web content is needed just let me know, my company provides WSGI hosting service so I probably can easilly get hosting for anything needed by TG for free. Now, why would that fail or be overly difficult to manage? It won't fail, but in my opinion is just more complicated to manage than being able to push to both 2.2 and 2.1 branches and just tag both the new 2.1.1 and 2.2 releases. Just my two cents, in the end I'm open to working with any branching strategy. TG is a quite linear project. 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. Thanks, I'll take a look right now. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Thu, Feb 17, 2011 at 7:23 PM, Christoph Zwerschke c...@online.de wrote: Am 17.02.2011 17:50 schrieb Michael Pedersen: I'll get myself logged into it tonight and check it out. I'm not going to promise anything. I will say that it looks promising, though. Then again, github looks promising, too. Part of me wonders if we might not be better off with github vs SF, too. Some of what they offer looks amazing in comparison. Concerning flow.io please don't misundertand me, I don't propose it as an alternative bug tracker, just as an additional tool for handling the high level management tasks which are not directly related to the code and relatively few compared to the number of trac tickets. And yes, github is not bad, but I think the bugtracker is also their weak point. I'm currently busy but also want to evaluate the SF hosted trac option this weekend, so please wait until I could have a look before making any drastic moves. Also, maybe you can talk with the SF support team via IRC (#sourceforge at freenode) regarding the forge tracker documentation. They are usually very responsive and helpful. If you are interested in a as a service project management tool also take a look at http://www.assembla.com/ we used it for a few project and it is quite good. It is also free for opensource projects. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
I'll talk to folks on this end and make sure we get the migration API docs pushed out into a publicly accessible place. --Mark Ramm On Wed, Feb 16, 2011 at 10:48 PM, Michael Pedersen m.peder...@icelus.org wrote: On Wed, Feb 16, 2011 at 6:44 AM, Christophe de Vienne cdevie...@gmail.com wrote: IMHO it is worth fully migrating to SF, even if limited - having to maintain those tools should not be a burden for the dev team. As for the hosted trac, I would avoid it in the long term. We want to migrate to SF entirely, make no mistake. What we're saying is that, right now, we might not be able to do so. At the least, the code is now in git, and the git repositories are hosted on SF. I've even prepped up a possible bit of web work that, once everything else is ironed out, could work for the web presence under the pylonsproject pages. Even with all that, without issue tracking, we've got nothing. And without being able to migrate our current issues into the SF base, we can't complete the migration to SF. If we can't get the migration to occur (due to lack of docs), let's at least not hamper ourselves with outdated software. We can upgrade Trac, so let's make that happen. It might require me setting up a linode instance to get full/proper Trac support with git and multiple setups, but I'll deal with that when it comes down to it. On Wed, Feb 16, 2011 at 6:50 AM, Alessandro Molina alessandro.mol...@gmail.com wrote: Stable code related to the in development version or code of stable releases? As I think that it is usually better to have development code on master and stable releases on their own branches as it makes easier to release patches and fixes for that specific release. Well, what I'm reading makes me think that the common/accepted practice for git is to have the master branch be the nothing happens here branch. Basically, whenever a development cycle is closed, the tag gets applied, everything gets migrated to master, and the development branch picks up new topic branches from there. This seems to have an advantage that all code (security fixes, especially) will eventually find its way to the master HEAD, or it's not fully integrated, and there's no question about it. Having a branch for all 2.1 code would allow a security fix to be applied only to 2.1, and never applied to master, and that would be (almost guaranteed) wrong. I'm open to hearing why my understanding is wrong, though. I'm not a git master, and am willing to be shown a better path. Not a problem, it would be better just to have them on sf.net for later inclusion than having them on a forgotten bitbucket project :D Now that I can agree on wholeheartedly. As of right now, I think I'm going to say to fork a git repository on SF.net. From there, make a branch and add Chris's changes to it. Send a pull request, and I'll sync it back up so that it's available for everybody. Oh, and I did just check it out. That does all work. I've even added a pu branch for proposed updates. Put the new dispatch work in as a branch from pu, and we'll go from there. BTW, before you think I came up with pu from thin air, I swiped the name directly from Git itself. It's what they use to start a controversial change, so I figure it should be able to work for us, too. On Wed, Feb 16, 2011 at 8:01 AM, Christoph Zwerschke c...@online.de wrote: You mean Trac in general, or a hosted Trac on SF? I can imagine using a current Trac version on our own server, as one instance with two (or three) Trac environments for TG1 and TG2 (and TG3), each configured to use the corresponding repository. For TG2 (and TG3) we would need the Git plugin as Trac has built-in support only for SVN. I'll admit to being confused still: Which machine is Florent's? Where does the current www.turbogears.org actually point? Can we even possibly make the git plugin work on the current www.turbogears.org, or do we need to switch things around so that Trac will work? On Wed, Feb 16, 2011 at 10:48 AM, Kevin Horn kevin.h...@gmail.com wrote: This is a would be really great to have happen. I think there may be a bit much going on right now to get too wrapped up in it, but it should definitely be on the radar. CI in particular would be a great help. We're not going to have it for 2.1.1. Can't be done in a reasonable enough time frame. 2.2, though, is a whole different beast. I want to see these tests there. As far as integration/performance tests, what were you thinking? Behavior-driven tests, using something like Lettuce or PyCukes? Scripted installations? Something else? I'm thinking that we should be able to do the following: full unit testing with 100% coverage testing of the installation from scratch (ultimately, on a variety of platforms) performance testing (using pystones to benchmark the machine, and then using that to normalize the requests/second for a few pages out of a quickstarted application)
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
There is a Trac import and export script example for sf.net here: http://sourceforge.net/p/allura/git/ci/e1c0a20357afc3af25f470cc3488ad3d5127c352/tree/migrate-3rdparty/ On Thu, Feb 17, 2011 at 11:50 AM, Michael Pedersen m.peder...@icelus.org wrote: I'll get myself logged into it tonight and check it out. I'm not going to promise anything. I will say that it looks promising, though. Then again, github looks promising, too. Part of me wonders if we might not be better off with github vs SF, too. Some of what they offer looks amazing in comparison. I'm still holding off on finalizing migration choices until this weekend. Hopefully Florent will speak up and/or we'll find the migration docs up on SF.net. Something will happen this weekend, though. I just don't know what. On Thu, Feb 17, 2011 at 11:30 AM, Christoph Zwerschke c...@online.de wrote: Am 17.02.2011 16:18 schrieb Michael Pedersen: So, what's the difference between using Trac tasks and flow.io http://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 would use flow.io for coordinating the general project management related tasks and workflow and Trac for keeping track of concrete, detailed development tasks directly related to the code. The advantage of flow.io is that you see who is working on what at the moment and get a nice overview of what has been done recently and what needs to be done next. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 17.02.2011 23:36 schrieb Mark Ramm: I'll talk to folks on this end and make sure we get the migration API docs pushed out into a publicly accessible place. Thanks, Mark. Maybe the export/import scripts are already sufficient for our needs, but that would help anyway. We probably need to make some adjustments, e.g. map Trac usernames to SF usernames (at least for the core developers). @Michael: We should prolong the ultimatum for the SF tracker migration now that we have some code and hopefully soon also docs for the tracker API. We need some time to experiment with this. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Thu, Feb 17, 2011 at 1:23 PM, Christoph Zwerschke c...@online.de wrote: Concerning flow.io please don't misundertand me, I don't propose it as an alternative bug tracker, just as an additional tool for handling the high level management tasks which are not directly related to the code and relatively few compared to the number of trac tickets. I'm thinking that I can see how the two sides link together. I've sent the email asking how we can sign up for the free solution, and we'll see what happens from there. And yes, github is not bad, but I think the bugtracker is also their weak point. Since I've not used their bug tracker, I can't argue for or against it at all. I'm glad someone else can fill me in before I go down a bad path, though. Thank you. I'm currently busy but also want to evaluate the SF hosted trac option this weekend, so please wait until I could have a look before making any drastic moves. Also, maybe you can talk with the SF support team via IRC (#sourceforge at freenode) regarding the forge tracker documentation. They are usually very responsive and helpful. I'll hold off on doing anything with the tracker, or with getting a VPS, until you send word back. Since you seem to have that well under control, I'll leave it to you. Between now and then, I guess the next thing to do is for me to get to work on making 2.0.4 happen. I'll see how much I can get done for that tonight. On Thu, Feb 17, 2011 at 4:44 PM, Alessandro Molina alessandro.mol...@gmail.com wrote: If hosting for TG web content is needed just let me know, my company provides WSGI hosting service so I probably can easilly get hosting for anything needed by TG for free. I don't mind paying for the hosting. If we get large enough, though, having sponsors would be a good thing. That's a ways off, though. It won't fail, but in my opinion is just more complicated to manage than being able to push to both 2.2 and 2.1 branches and just tag both the new 2.1.1 and 2.2 releases. Just my two cents, in the end I'm open to working with any branching strategy. TG is a quite linear project. I don't know. I'm going to continue to learn more about git before I make that final choice. Since 2.0.4 is on a branch that really doesn't have much of anything to do with 2.1 (well, history/commit wise, anyway), I'm going to keep it on its own branch, I think. Time to start getting patches/fixes in place, I think. On Thu, Feb 17, 2011 at 4:48 PM, Alessandro Molina alessandro.mol...@gmail.com wrote: If you are interested in a as a service project management tool also take a look at http://www.assembla.com/ we used it for a few project and it is quite good. It is also free for opensource projects. I took a look at them tonight. They seem like something I've been looking for for work. Not sure about their pricing, but I'm going to suggest it. However, I think that they might be too much for TG right now, especially with our trying to get migrated to SF (that is still the overall desired goal). I know that we don't have to use all of their features, but it definitely seems a shame not to. For us, I don't think they're a good fit. At least, not as good as flow.io. On Thu, Feb 17, 2011 at 5:36 PM, Mark Ramm mark.mchristen...@gmail.comwrote: I'll talk to folks on this end and make sure we get the migration API docs pushed out into a publicly accessible place. Thanks Mark! I do appreciate it. We really do want to switch entirely to SF. On Thu, Feb 17, 2011 at 8:12 PM, Christoph Zwerschke c...@online.de wrote: @Michael: We should prolong the ultimatum for the SF tracker migration now that we have some code and hopefully soon also docs for the tracker API. We need some time to experiment with this. Agreed. I'm thinking that we'll hold off on a finalized choice until I can get the work completed for 2.0.4. At that point, we have to do something. Now, to find out how much work that actually *is*... -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Tue, Feb 15, 2011 at 4:15 PM, Michael Pedersen m.peder...@icelus.org wrote: On Tue, Feb 15, 2011 at 8:44 AM, Alessandro Molina alessandro.mol...@gmail.com wrote: I have seen that on sf.net there are only 2.0 and master branches. How do you plan to handle a branching strategy for future development? I'm still somewhat in the air about this, honestly. Right now, I'm thinking that stable code only will go into master, with development branches occurring. Been reading Professional Git, andf I'll admit it's shaping a lot of my thinking. That doesn't mean it's always right, so I'm keeping myself open to other ides. Stable code related to the in development version or code of stable releases? As I think that it is usually better to have development code on master and stable releases on their own branches as it makes easier to release patches and fixes for that specific release. Personally I would suggest to have a branch for each stable release where we can just commit fixes. Currently we should have something like: 2.0 2.1 2.2 The one major change I would make is that I would not make a 2.2 branch as yet. Right now, the current order of operations needs to be this: Complete migration to sourceforge.net Release 2.0.4 (we have some minor bugfixes ready for it) Release 2.1.1 (again, minor bugfixes already ready) Begin work on 2.2. Fine, I think that it is a good plan. The 2.2 work should probably be based on the percious work to move dispatch to crank if we want to procede in that way. I did some work on https://bitbucket.org/_amol_/tg-2.2/overview to merge his work with the old tip of the TG repository. Let me know if there is any interest to move that work on sf.net and I'll migrate it to git. Interest? Yes. However, here's where my first significantly unpopular decision is likely to happen. I don't think we can incorporate those changes for 2.2. We have way too many issues that need to be resolved. Open bugs in the code and in the documentation, and a major documentation overhaul, are all required fixes. Changing the dispatch mechanism again? I don't think I can get behind that as yet. Our API is too undocumented, too unstable, and it's causing chaos. Every release, we're deprecating how dispatch happens. This is not good for our users, and therefore is ultimately not good for us. Getting the changes migrated in on their own branch could be a good thing. However, they would belong off of a proposed updates branch, and not merged for some time. Not a problem, it would be better just to have them on sf.net for later inclusion than having them on a forgotten bitbucket project :D I have a strong feeling that we should enforce a set of stable libraries tested with TG. Currently the main problem most people have is that if they install TG it will work or not depending on the current status of the libraries on the PyPI env and we cannot be sure that each library used by TG will continue to work with TG. Agreed. That's why I'm looking to force the installers to use our private PyPI as their first repository. It makes us responsible for keeping our copies of the .egg files current, but that's a small price to pay for being able to say easy_install tg.devtools or pip install tg.devtools. Great, im my opinion having reliable releases that install flawlessly is fundamental for a framework, especially if you want to capture software development companies interest. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 16.02.2011 03:47 schrieb Michael Pedersen: You missed the documentation being fixed. That, in fact, is the only item on my list that you didn't mention. We're definitely agreeing on the needs of TG2. 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. Another idea to push things forward: We could use http://flow.io for managing the higher level project management, coordinating our efforts, keeping track of what needs to be done and spreading the workload. It might be a good idea, I just don't know enough about it. Never seen it, never used it, never heard of it before now. And I still have to finish learning enough of git to be comfortable. I don't think I can pick up another new tool yet. flow.io is not a complicated tool, you can use it intuitively without learning efforts. And open source projects can use it for free. It could remind us of all the open tasks we discussed and would show who is working on what so that we do not suddenly start to work on the same thing at the same time. As some more people like Florent want to join the project team it is important to coordinate our efforts so we don't step on each others toes. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 17.02.2011 04:48 schrieb Michael Pedersen: I'll admit to being confused still: Which machine is Florent's? Where does the current www.turbogears.org http://www.turbogears.org actually point? 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. As far as integration/performance tests, what were you thinking? Behavior-driven tests, using something like Lettuce or PyCukes? Scripted installations? Something else? I'm thinking that we should be able to do the following: * full unit testing with 100% coverage * testing of the installation from scratch (ultimately, on a variety of platforms) * performance testing (using pystones to benchmark the machine, and then using that to normalize the requests/second for a few pages out of a quickstarted application) * Possibly scripting tests for a few extensions and making sure they work properly (such as tgext.admin) 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. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
[tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Feb 15, 12:20 am, Michael Pedersen mjpe...@gmail.com wrote: Weekly status roundup: *TG2.1 / SQLAlchemy Bug* So, it seems that, with 2.1 and SQLAlchemy 0.7 beta, we have a bug. For now, the short term fix is to make sure to get users to install 0.6.6. The only question is *how* to make this happen. My initial response was to tell people to use our private PyPI. The immediate response is They don't do it now, and we tell them to do so, why will they start listening? So, I have a different proposed solution: We change our setup.py to include our private PyPI in the list of places to look. As much as possible, we even force it to be the *first* place to look. Now, people can make end runs around this issue, and it won't fix existing applications, but if we put this into our quickstart, it will take care of the issues pretty nicely. As an added bonus, it also prevents future problems. The drawback is that, since we're in the middle of a migration, and URLs are changing, I wouldn't want to push this update until at least the web migration is complete. Both the methods you suggest have been tried before and both have failed. Forcing our pypi index, has the opposite problem, if there is a mayor security release, or something that unbreaks something that broke really bad (look for the Extremes package for an example of how it was broken in our pypi and fixed in regular pypi. Putting it into the quickstart has the problem that everyone with the current version of TG will get a broken build. Also it's conceptually wrong your app does not depend on SA 0.6.6. Turbogears does, more specifically repoze.what.plugins.sql therefore *TG* should have the restriction (at least until r.what is fixed) -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Mon, Feb 14, 2011 at 11:59 PM, Kevin Horn kevin.h...@gmail.com wrote: On the SA list, Mike Bayer made it sound like he's planning on pulling the 0.7beta off of PyPI for the time being. If that is indeed the case, you might want to factor that into whatever plan ends up being made. In that case, we get slightly more time until the next version of 0.7 beta comes out. I'll be surprised if it's more than two weeks, though. On Tue, Feb 15, 2011 at 8:34 AM, jorge.var...@gmail.com jorge.var...@gmail.com wrote: Both the methods you suggest have been tried before and both have failed. So, the solution you're demanding is that we start requiring specific versions, even when those versions may no longer be available on standard PyPI in future? Since that's not actually a viable option, and since our docs already tell people to use our PyPI, unless you can provide another option, we're probably going to have to go with forcing our PyPI. On Tue, Feb 15, 2011 at 8:39 AM, Christophe de Vienne cdevie...@gmail.comwrote: What I do in my own projects is to require SQLAlchemy0.6.99. This way I am sure pre-0.7 version don't get installed while bugfix releases on the 0.6.x branch do. And when I get compatible with 0.7.x, then I change the requirement to 0.7.99. This is a viable way of specifying the requirements, definitely. I'd actually go with 0.7 and 0.8, though. This way, if version 0.6.99 *does*come out, then you will still get it. On Tue, Feb 15, 2011 at 8:44 AM, Alessandro Molina alessandro.mol...@gmail.com wrote: I have seen that on sf.net there are only 2.0 and master branches. How do you plan to handle a branching strategy for future development? I'm still somewhat in the air about this, honestly. Right now, I'm thinking that stable code only will go into master, with development branches occurring. Been reading Professional Git, andf I'll admit it's shaping a lot of my thinking. That doesn't mean it's always right, so I'm keeping myself open to other ides. Personally I would suggest to have a branch for each stable release where we can just commit fixes. Currently we should have something like: 2.0 2.1 2.2 The one major change I would make is that I would not make a 2.2 branch as yet. Right now, the current order of operations needs to be this: - Complete migration to sourceforge.net - Release 2.0.4 (we have some minor bugfixes ready for it) - Release 2.1.1 (again, minor bugfixes already ready) - Begin work on 2.2. The 2.2 work should probably be based on the percious work to move dispatch to crank if we want to procede in that way. I did some work on https://bitbucket.org/_amol_/tg-2.2/overview to merge his work with the old tip of the TG repository. Let me know if there is any interest to move that work on sf.net and I'll migrate it to git. Interest? Yes. However, here's where my first significantly unpopular decision is likely to happen. I don't think we can incorporate those changes for 2.2. We have way too many issues that need to be resolved. Open bugs in the code and in the documentation, and a major documentation overhaul, are all required fixes. Changing the dispatch mechanism again? I don't think I can get behind that as yet. Our API is too undocumented, too unstable, and it's causing chaos. Every release, we're deprecating how dispatch happens. This is not good for our users, and therefore is ultimately not good for us. Getting the changes migrated in on their own branch could be a good thing. However, they would belong off of a proposed updates branch, and not merged for some time. I have a strong feeling that we should enforce a set of stable libraries tested with TG. Currently the main problem most people have is that if they install TG it will work or not depending on the current status of the libraries on the PyPI env and we cannot be sure that each library used by TG will continue to work with TG. Agreed. That's why I'm looking to force the installers to use our private PyPI as their first repository. It makes us responsible for keeping our copies of the .egg files current, but that's a small price to pay for being able to say easy_install tg.devtools or pip install tg.devtools. -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 15.02.2011 14:47, schrieb Alessandro Molina: On Tue, Feb 15, 2011 at 2:34 PM, jorge.var...@gmail.com jorge.var...@gmail.com wrote: Both the methods you suggest have been tried before and both have failed. Forcing our pypi index, has the opposite problem, if there is a mayor security release, or something that unbreaks something that broke really bad (look for the Extremes package for an example of how it was broken in our pypi and fixed in regular pypi. We have off course to keep our pypi updated when fixes for the libraries that we use appear. This shouldn't be a problem as we use TG ourselves and so we know when it won't install anymore. I wanted to answer the same, I don't see the problem with the approach itself, but with us failing to properly maintain our own PyPI. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 15.02.2011 16:15, schrieb Michael Pedersen: This is a viable way of specifying the requirements, definitely. I'd actually go with 0.7 and 0.8, though. The problem with that is that setuptools considers 0.7a1, 0.7b1, 0.7rc1 all 0.7 (which makes some sense). So 0.7a1 is probably what you want. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Le 15/02/2011 16:28, Christoph Zwerschke a écrit : Am 15.02.2011 16:15, schrieb Michael Pedersen: This is a viable way of specifying the requirements, definitely. I'd actually go with 0.7 and 0.8, though. The problem with that is that setuptools considers 0.7a1, 0.7b1, 0.7rc1 all 0.7 (which makes some sense). So 0.7a1 is probably what you want. What about 0.7dev ? Christophe -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 15.02.2011 16:46, schrieb Christophe de Vienne:
What about 0.7dev ?
Right, 0.7dev is sorted even before 0.7a
with the current setuptools and distutils:
from pkg_resources import parse_version as V
V('0.7.dev1') == V('0.7dev1') V('0.7a1') V('0.7b1') V('0.7')
True
However, 0.7dev is not valid and 0.7.dev 0.7a
with the newly proposed version schema of PEP386:
from verlib import NormalizedVersion as V
V('0.7a1') V('0.7b1') V('0.7.dev1') V('0.7')
True
V('0.7dev')
verlib.IrrationalVersionError: 0.7dev
So maybe we need to combine both: 0.7.dev1, 0.7a1
-- Christoph
--
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com.
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en.
[tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Feb 15, 4:29 pm, Michael Pedersen m.peder...@icelus.org wrote: On Tue, Feb 15, 2011 at 4:08 PM, Kevin Horn kevin.h...@gmail.com wrote: Maybe there should be a TG-based private PyPI app that can be told to check for new versions? And then expose them to the private PyPI when instructed to? Perhaps it could take some kind of switch or something so that devs/testers would get the latest version of all packages, while the general users would get only the approved versions? Dammit. Now I have another new item on my todo list. I haven't even managed to cross all the other items off of it yet! Yes, I like this idea, quite a bit. Set up a scheduled job to pull down new versions, let people download testing/etc versions. This is an excellent idea. Thank you. For the record, I just looked on PyPI and SQLAlchemy 0.6.6 is now again the latest there (Mike seems to have removed 0.7dev). -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
