On Wed, Feb 16, 2011 at 6:44 AM, Christophe de Vienne <[email protected]>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 < [email protected]> 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 <[email protected]> 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 <[email protected]> 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) - Possibly scripting tests for a few extensions and making sure they work properly (such as tgext.admin) And yes, I do want to get at least the first three items for 2.2. I'm going to try to hold off discussing what I want there until we've got 2.1.1 out the door, though. No need to rush that discussion, not yet. -- 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.
