Should other repositories move to Bazaar/LP?
Well, that's the question. Things like webpage and others. I have no opinion as I rarely edit them, but I thought I'd throw this out there while I still remember all the deep magic involved with converting things ;)
--Ted
On 11/29/09, Ted Gould wrote:
Well, that's the question. Things like webpage and others. I have no opinion as I rarely edit them, but I thought I'd throw this out there while I still remember all the deep magic involved with converting things ;)
As fore webpage repository, someone would have to install bzr client on our server, if there is none currently, and edit the script that we use to fetch data from repository to server accordingly. On the other hand, wasn't there a plan to switch to a different CMS anyway? Can't speak for other repositories.
Alexandre
On Sun, 2009-11-29 at 09:27 +0300, Alexandre Prokoudine wrote:
On 11/29/09, Ted Gould wrote:
Well, that's the question. Things like webpage and others. I have no opinion as I rarely edit them, but I thought I'd throw this out there while I still remember all the deep magic involved with converting things ;)
As fore webpage repository, someone would have to install bzr client on our server, if there is none currently, and edit the script that we use to fetch data from repository to server accordingly. On the other hand, wasn't there a plan to switch to a different CMS anyway? Can't speak for other repositories.
For the website, there are plans to move to a proper CMS (Drupal specifically).
Cheers, Josh
I'm planning on us using the Backup and Migratehttp://drupal.org/project/backup_migratemodule for Drupal to back up the database regularly, and changes will have to be via the website (or for big things where you're sure you won't break anything, SQL queries). External version control is out with all (serious) content management systems as entirely unmanageable (I'm not aware of any CMS which has tried).
On Sun, Nov 29, 2009 at 12:39 PM, Joshua A. Andler <scislac@...400...>wrote:
On Sun, 2009-11-29 at 09:27 +0300, Alexandre Prokoudine wrote:
On 11/29/09, Ted Gould wrote:
Well, that's the question. Things like webpage and others. I have no opinion as I rarely edit them, but I thought I'd throw this out there while I still remember all the deep magic involved with converting things ;)
As fore webpage repository, someone would have to install bzr client on our server, if there is none currently, and edit the script that we use to fetch data from repository to server accordingly. On the other hand, wasn't there a plan to switch to a different CMS anyway? Can't speak for other repositories.
For the website, there are plans to move to a proper CMS (Drupal specifically).
Cheers, Josh
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Chris Morgan <chris.morganiser@...400...>
I'm good at making two things: mistakes and enemies.
On 11/29/09, Chris Morgan wrote:
I'm planning on us using the Backup and Migratehttp://drupal.org/project/backup_migratemodule for Drupal
After just having recommended Django? :)
Alexandre
On Sun, Nov 29, 2009 at 3:15 PM, Alexandre Prokoudine < alexandre.prokoudine@...400...> wrote:
On 11/29/09, Chris Morgan wrote:
I'm planning on us using the Backup and Migratehttp://drupal.org/project/backup_migratemodule for Drupal
After just having recommended Django? :)
That was for the extensions repository. The website is using Drupal and that's good. For that, Drupal's much easier to use than Django (and using Django for it just wouldn't be worth it I don't think).
Alexandre
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Chris Morgan <chris.morganiser@...400...>
I'm good at making two things: mistakes and enemies.
On Sun, Nov 29, 2009 at 3:19 PM, Chris Morgan <chris.morganiser@...400...>wrote:
On Sun, Nov 29, 2009 at 3:15 PM, Alexandre Prokoudine < alexandre.prokoudine@...400...> wrote:
On 11/29/09, Chris Morgan wrote:
I'm planning on us using the Backup and Migratehttp://drupal.org/project/backup_migratemodule for Drupal
After just having recommended Django? :)
That was for the extensions repository. The website is using Drupal and that's good. For that, Drupal's much easier to use than Django (and using Django for it just wouldn't be worth it I don't think).
On second thoughts, it could be good to have it all integrated and all powered by Django. We're getting along OK with Drupal, but in many ways Django would be better - provided someone has the time to set it up. A Django project for it would be able to use a filesystem-based content management system (e.g. djangoproject.com's codehttp://code.djangoproject.com/browser/djangoproject.com/django_website), so we could use Bazaar for it and pull and push content very easily without needing to log in to the website, etc., and (BIG plus here which we just can't really do properly with Drupal, so we wouldn't be able to have a purely Drupal system) could also replace the MediaWiki wiki properly with py-wikimarkup http://github.com/dcramer/py-wikimarkup (we could then also gradually shift over to reStructuredTexthttp://docutils.sourceforge.net/rst.htmlwhich is the recommended - and very good - documentation, etc. format; lots of things use it, say even that py-wikimarkup readme file is RST). The more I actually *think* about it, I think that doing the Inkscape website in Django would be better. It would take a bit longer than Drupal to get started for just basic content and all (is there anyone else in the community familiar with Django? I won't have endless time, I'm working on my own commercial Django project), but it would be much faster for other things - say the wiki, and an extensions repository - and it would all be integrated. I think we could still get it up and going before 0.48. I think that if we have a couple of other people who can do Django stuff, we could probably get it integrated faster than Drupal. Not needing to worry with moving from a file-based content system to a database-based ditto has some great advantages.
I change my vote from Drupal to Django.
-- Chris Morgan <chris.morganiser@...400...>
I'm good at making two things: mistakes and enemies.
On 11/29/2009 10:22 AM, Chris Morgan wrote:
It would take a bit longer than Drupal to get started for just basic content and all (is there anyone else in the community familiar with Django?
I don't, but I'd be happy to help where I can.
What needs to be done to set up an initial site and get it into a bzr repo? That way, those who are interested in helping can get familiar with it and possibly start building.
As for content migration, how would this be done (especially considering the wiki)? I assume the content files could easily be parsed to work with Django.
Would the extension repo idea be able to be worked into this, then? I mean, I know it would, but would we want to do that?
JF
On Mon, Nov 30, 2009 at 12:02 PM, Joshua Facemyer <jfacemyer@...400...> wrote:
On 11/29/2009 10:22 AM, Chris Morgan wrote:
It would take a bit longer than Drupal to get started for just basic content and all (is there anyone else in the community familiar with Django?
Yes and no - I've used Django with Turbogears, but only for playing around/learning. I'll be digging more into it this week during my off time though - it's very nice so far.
Would the extension repo idea be able to be worked into this, then? I mean, I know it would, but would we want to do that?
I spent quite some time yesterday trying to get Django installed on a Sourceforge hosting account - it was not pretty :( In short, it would be messy (install a local Python along with dependencies for Django, then run the whole mess through fcgi - and I'm not entirely sure it's possible after all).
And while I'm rambling on - what about trying Turbogears as a framework? Sourceforge is moving to it (though I doubt that they will be using the default cherrypy server). At any rate, I will be playing around with Django and probably TG this week to prototype the extension repo. Whether or not the extension repo becomes an addon to the main site, I'm happy to help.
Chris
On 29/11/09 07:20, Ted Gould wrote:
Well, that's the question. Things like webpage and others. I have no opinion as I rarely edit them, but I thought I'd throw this out there while I still remember all the deep magic involved with converting things ;)
Are there plans to move the testsuite as well? Johan has asked to add any suitable test files from SVG/renderer bug reports to the testsuite, maybe it could help this process if both bug tracker and gsoc-testsuite are hosted on launchpad... http://inkscape.svn.sourceforge.net/viewvc/inkscape/gsoc-testsuite/
@Josh - if the testsuite stays on sf.net, is it possible that I get SVN access to commit test files from the bug tracker?
~suv
Are there plans to move the testsuite as well? Johan has asked to add any suitable test files from SVG/renderer bug reports to the testsuite, maybe it could help this process if both bug tracker and gsoc-testsuite are hosted on launchpad... http://inkscape.svn.sourceforge.net/viewvc/inkscape/gsoc-testsuite/
Is there a compelling reason not to have the rendering testsuite somewhere in the trunk? I could integrate it with 'waf check' that I'll shortly be working on.
Regards, Krzysztof
On Nov 29, 2009, at 7:42 AM, Krzysztof Kosiński wrote:
Are there plans to move the testsuite as well? Johan has asked to add any suitable test files from SVG/renderer bug reports to the testsuite, maybe it could help this process if both bug tracker and gsoc-testsuite are hosted on launchpad... http://inkscape.svn.sourceforge.net/viewvc/inkscape/gsoc-testsuite/
Is there a compelling reason not to have the rendering testsuite somewhere in the trunk? I could integrate it with 'waf check' that I'll shortly be working on.
There are a few reasons. Among them is the size of the items, especially as we build up binary images of various tests.
Another large factor is the current effort under the SVG Interest Group to collect and publish stress tests.
Oh, and just a quick reminder that any make with check should be focusing on the cxxtest unit tests we have.
De : Ted Gould <ted@...11...>
Well, that's the question. Things like webpage and others. I have no opinion as I rarely edit them, but I thought I'd throw this out there while I still remember all the deep magic involved with converting things ;)
I use the doc-docbook trunk quite often, in order to generate the tutorials included in Inkscape and exported to the web site. I have no problem with SVN, but I'd rather use the same system for all Inkscape related sources.
Regards, -- Nicolas
participants (10)
-
Alexandre Prokoudine -
Chris Mohler -
Chris Morgan -
Jon Cruz -
Joshua A. Andler -
Joshua Facemyer -
Krzysztof Kosiński -
Nicolas Dufour -
Ted Gould -
~suv