> we'd like to move the management of the core TiddlyWiki code from > http://svn.tiddlywiki.org/ to a to be determined location on GitHub
That'd be great. In fact, it almost seems like a necessary (if not sufficient) step in order to bring about some reinvigoration. FWIW, I registered https://github.com/TiddlyWiki a few years ago (I guess I was hoping for this move to occur sooner... ) - and would of course be happy to hand over the credentials. > The proposal is based on the idea that the web works. All stuff > doesn't need to be in the same place, because if things have URIs > then they can be anywhere on the web. +1 > What portion is to be moved? Off the top of my head, I can think of these basic/official components: * TiddlyWiki core (Trunk/core/, along with tests and such) * Cook (Trunk/tools/cooker/) * jQuery plugins (Trunk/core/jquery/plugins/) Each of those could, and probably should, be a separate repository. Ideally, their respective directory structures should be reviewed/reorganized. > What happens to those parts that are not moved? Just leave them in SVN, from where they can be migrated individually as necessary (e.g. contributors' and some of the association stuff would probably be migrated eventually by their respective maintainers). > Of those pieces that move, will they all go to the same place? I don't think so - see above. > Will history be moved? For almost every component, history has proven very important over the years (<obligatory note about commit messages>) - so we should try our best to retain that. I'm pretty sure git-svn supports partial cloning, so it shouldn't be much of a problem. > If you are one of those contributors and you are concerned, please > speak out. I'm not actually concerned, but it's worth mentioning that most verticals' recipes will probably stop working - unless, perhaps, the existing TiddlyWiki core recipe(s) remain in place, essentially just redirecting to the new URIs. > trac and the tickets therein will also be frozen in a read only > state. tickets will _not_ be migrated. The goal here is to get rid of > stale tickets and the most straightforward way to do that is to let > important tickets be recreated I approve. > in the github issues system > [...] > This is still very open for debate as there's some concern that > github issues system is not up to the task. This has not been my > experience, in fact I rather like it. I'm not a huge fan of GitHub Issues - but then, all issue trackers suck. >From our TiddlySpace experience, GHI is good enough, probably even better than Trac (if only because it's less bloaty, though it also has a nice API). So sure, I approve. (Note that a GitHub account is required to raise tickets there - but that's not necessarily a bad thing; there's always the mailing lists.) -- F. -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" 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/tiddlywikidev?hl=en.
