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 <[email protected]> wrote: > 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. > -- 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 [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.
