On Fri, 03 Apr 2015 00:16:27 +0100 Bertrand Jacquin <bertr...@jacquin.bzh> said:
> On 02/04/2015 04:21, Carsten Haitzler wrote: > > On Wed, 01 Apr 2015 22:19:53 +0100 Bertrand Jacquin > > <bertr...@jacquin.bzh> said: > > > >> On 31/03/2015 23:46, Carsten Haitzler wrote: > >> > On Tue, 31 Mar 2015 17:33:03 +0100 Bertrand Jacquin > >> > <bertr...@jacquin.bzh> said: > >> > > >> >> Hey, > >> >> > >> >> On 31/03/2015 15:51, Stefan Schmidt wrote: > >> >> > >> >> > o Talk to beber to remove the old trac webservice to make sure we have > >> >> > less outdated information [assigned: Stefan] > >> >> > >> >> Do you want me to drop trac.e.org ? Do you want the content of > >> >> trac.e.org be moved to phab (That is pain is the ass to do) ? Or to > >> >> drop > >> >> phab content already migrated from trac ? > >> > > >> > just drop it. :) no one is referring to the old content anymore :) and > >> > chances > >> > are the vast majority is out of date by now. > >> > >> trac is dead, long life to phabricator > > > > and while we are discussing web things... i've been messing with > > replacing our > > www custom php with a standard wiki that ... works for us. i've tried a > > LOT of > > them. a LOT. i finally found one that "works": dokuwiki. > > dokuwiki is great. What is wrong with Phab one ? i'd use phab - if we could remove all the phab bits. - ie style it properly to replace www.e.org - i can't find a way to do that. not supported. would have to patch phab heavily for that. phab can do it for blogs, not the wiki. but phab doesnt have stuff in nice plain files in a file tree. dokuwiki does. makes it trivial to script tools to fill/seed/modify the tree. :) > > 1. it's in php (easy drop in for what we have). > > 2. we can keep shot.php and update.php in the doku tree > > 3. it is a plain file wiki (yay! no db!) > > 4. it has a git back-end where the web content can be put in a separate > > git > > repository! (more yay!) and wiki edits on www get committed, and > > commits to the > > git repo directly get pulled in every N minutes. > > +1 > > > 5. its markdown is powerful enough for what we need > > 6. it has code hilighting and more that is decent > > 7. styling/templating/layout is flexible enough to make e.org look > > good. > > I'll let you do that magic i'm already done. https://www.enlightenment.org/ss/e-551cfeec2c5fc0.69966413.png running locally atm. it won't take much to simply dump that on e.org, fix up some config and ... BOOM. atm i'm filling it with content so it can replace e.org's useful bits. i'm taking the opportunity to trim stuff down as a result. > > 8. has actual users and authentication. (unlike some... errm gollum) > > 9. doesn't seem to require any exotic php modules or extensions etc. > > true > > > so how do you want to do this? i have prepared a new www git tree (have > > some > > conflicts that will need to basically be thrown out). > > I'd prefer a branch over current www.e.org git repo with existing > history to make things more clear to follow. ? why a branch? dokuwiki would just replace our current www tree. actual wiki CONTENT (pages, media) is a separate git repo entirely... i actually committed a dokuwiki tree to my local git tree of www - if i just git push it'd be up. :) you keep all history of our old www tree. nothing lost. :) > > i have a test www-content > > git repo in my devs git repos. i will populate that at least with > > enough > > initial content to make e.org usable again and then go from there. > > server-side > > this will need some config - eg like giving the www a devs account with > > an ssh > > priv key so the www server can commit to this www-content repo... i'd > > just > > actually give the http user on e.org all of that (and if it is ever > > abused/compromised we can nuke key access and revert any changes from > > that > > user). > > we can make sure the key will not be nuked by not letting www user > getting access to the private key (unix perm) but to let it use a > ssh-agent that can be launched at host startup. well whatever works - it'd need git commit access as a user to just one git repo in git.enlightenment.org - that means ssh key access. > > any comments/input? > > that sounds correct to me. I can create a new testing vhost for you on > the current www.e.org for tests. Can you want until next week end ? yes - it can wait. actually don't really need a testing host. it does work - it just needs a bit of set-up in place of current one. we can keep shot.php and the screenshots etc. etc. we have - just the rest of the php surrounding it switches over to new php stuff that is dokuwiki. i just need to clone a new repo there of www-content (and need a proper git repo not my devs one). it pretty much sounds like maybe a sunday morning "hack and set it up" effort on the current vhost (clone www content, test that it pulls/commits and is configured appropriately - that is actually the worst bit). it cant usefully go live without content being there, so i'm doing that atm. when that is done - we can switch and any updates/improvement to content is just a matter of editing the wiki (via its web ui or via git back-end locally and do commits+pushes). it can then improve over time. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
