[Bf-docboard] Bf-docboard Digest, Vol 92, Issue 7

[Dan McGrath]

Hi,

Thanks for the reply, glad to see someone reading another one of my
patent pending wall-o-texts XD

> I don't want to sound pedantic but the technical possibilities/limitations
> WILL have an effect on how your wiki will evolve, even if not directly
> affecting what's ALREADY there.

True they could, perhaps I should have been more clear. I was more
referring to the upgrade intentions and existing content look/feel.
More specifically, when everything is said and done, the goal isn't to
change wiki software and give a totally new look and feel or anything
radical like a reinstall from scratch, just upgrade the existing base
software and extensions. Is this more clear?

> As far as the backend goes, only some partial tests have been carried
> out using a multi branch git repo to manage the MediaWiki installation
> and deploy to the vhost directory using hooks.
>
> You mean, re-inventing the wheel ? (http://ikiwiki.info/)

Perfect, exactly the kind of suggestions I was looking for! Although,
I think you misunderstood what I was using git for. The aim was not to
use git for the wiki content (although, I think greylica had mentioned
it yesterday), which is what this ikiwiki looks like at a 10 second
glance, but for managing the php installation itself. Here are two
url's that went out to the admin team in an email that you would have
missed that give an idea of how I was looking at using git to manage
the mediawiki php files in a webserver vhost context:

  http://toroid.org/ams/git-website-howto
  http://danielmiessler.com/study/git/

Although thanks for the ikiwiki link! I was going to look at it to see
what it was after I had heard it mentioned by greylica. Sounds rather
interesting for a future project perhaps, but I think that is outside
of the scope of what I was originally looking to tackle.

> Things like file system
> locations, permissions, naming conventions and hook code, for example,
> need to have the details hammered out and finalized (Marco, got any
> time this week?), which I think should be coordinated with the server
> admin(s). At this point, even I am not exactly sure what the scope of
> the changes I should be aiming for are (clarification here Ton?), I
> was just handed the keys :D
>
> I don't yet know how much fine-grained you need the rights to be for the
> wiki, but assuming that every maintainer has the same rights, and every
> public client would have the same (but different?) rights too; it's really
> easy to set this up with gitolite.

Actually, I had my own gitosis install on one of my machines here last
year that I was playing around with some of my existing svn projects
imported into it, and was considering (which I mistakenly confused
with gerrit a few days ago in the blenderwiki channel, in case you
were listening to me speak there?) mentioning that to the admins
already in one of my "changelog" emails that I send out, but the name
had slipped my mind. I still am considering this type of central
setup, although seems that gitosis has been deprecated or something
(haven't looked into why yet tbh) in favor of gitolite, which honestly
sounds better. That being said, I have to run stuff like that past the
server admin since it is his box and he should be, imho, made aware of
services such of this before they are installed.

The fine grained rights I was discussing, were things like you would
use when you do a `git init --bare --shared`, which I figure you are
more than familiar with by the sound of your recommendations. The
problem isn't one of me being too stupid to manage unix permissions
hehe, it's more of a bicycle shed type problem; where do we want to
put this, what names do we want to use, will it be controlled via a
common unix group or via su or sudo (or, things like
gitosis/gitolite), etc. ie: all the little details that the server
administrator must be made aware of. Honestly, I do rather like the
idea of a general git repo that users can just get permissions to
create on the fly. But should such a thing be made as a more general
use feature for blender coders, or limited to this single purpose?
Depending on your answer, the setup needs to be adjusted accordingly
by the administrator, etc.

Also, by the sound of your comment, you may have confused what I said
to think that I wanted to do fine grained rights on the mediawiki
installation itself. To clarify, I had no intention of changing the
current installation configuration itself in anyway, other than what
might be needed for any upgrades in version numbers of extensions and
the base system itself. So there wouldn't have been any new
restrictions on who can edit pages or stuff like that.

That all being said, I think I seen your name tossed around once
before. Have I see you around before perhaps? Feel free to poke me on
irc if you feel like chatting or have other questions or similar. It
sounds like you might be interested in, or perhaps even starting work
on some of this very stuff yourself. Anyways, cheers! o/


Dan