[Cryptech Core] Project infrastructure: Trac, Gitolite, cgit, Gogs, and Pelican

[Peter Stuge]

Rob Austein wrote:
> At the moment, our wiki occasionally hangs,

Interesting. I haven't ever seen that while running a handful public
Trac instances.


> and the git repository browser is slow even when it's working.

Git is Trac's weak spot.

> Part of the problem is pretty clearly the git browser.

While there is git support in Trac out of box, Trac's data model makes
assumptions about repositories which aren't true for git and some other
repository types, in particular that history is linear and that
traversing commits both forwards and backwards are equally cheap.

As if this isn't bad enough, as you write the Trac implementation is
bad too. (It spawns git commands.) I've worked on a replacement using
pylibgit2 and that's the way to go for sure, but at maybe 95% done I
found that Trac couldn't really deal with multiple "next" commits and
shelved that effort.


> Losing content in the Wiki is also part of the problem: it's all
> there, somewhere, but most people seem unable to find half of it,
> and even for those of us with sufficient Trac-fu to find stuff, it's
> tedious.

Sorry what? I don't understand this one. Is content lost (missing
from the DB) or not? If not, could you explain this problem more?


>   1) Like GitHub, and like most other git hosting solutions, Gogs does
>      not support hierarchical trees of repository URLs.  It's a two
>      level space: owner/repository, where "owner" is either an
>      individual or an organization.

This and with wiki-per-repo makes Gogs a poor choice IMO.


> * If we just wanted to disable the Trac repository viewer and leave
>   Trac's wiki functions intact

GitWeb isn't amazing, but cgit is a good choice. The caching can need
some maintenance, but then it's nice and fast.


> * Pelican is a static content generation tool
..
>   The things that make it potentially useful here are:
> 
>   1) It's simple to set it up to work hand in hand with git: you just
>      add content by editing Markdown files, commit and push.

This is only a feature as long as every editor enjoys that workflow.

It fits developers, but I don't want to *require* git for editing if
that creates a hurdle, however minimal, for anyone who may possibly be
editing the wiki. I appreciate wiki contributions very much, and I want
to avoid making them even slightly less likely to happen.

I've had a similar situation before, but no real solution. :\

Is there a web UI for editing such repos that could be combined?


//Peter