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 ?

> 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

> 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.

> 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.

> 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 ?

-- 
Bertrand

------------------------------------------------------------------------------
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

Reply via email to