Site: Trac

[Tim Blokdijk]

AF made a suggestion for Trac based management of the site. And so far everybody agrees with this. I decided to open this topic to discuss this more in-depth. I know what Trac is although I never used it in practice so I can make a wrong assumption here or there, please correct me if so.

Trac would be really practical and supplement things in a very nice way, my work (requirement analysis, development processes, tech. documentation and version history) can be moved from the odf docs to the trac wiki.
Only the roadmap is overlapping but it's (far) more practical to use Trac for that.

But there are a few practical problems that need to be discussed.
- You need root rights to install it, is this practical?
- It's a bit like buildbot that it's part of the site but still a separate application outside www-root, how should we organize the dir structure?
- If we like svn integration we need to install in on Fnodia's server. This may take more time then a installation on a random server. What do we like to do?
- Trac is doing the same job as Mantis, is it practical to move everything to Trac? Or do we only use it for the site and Mantis for the engine?
- Trac has its own wiki, that means we will have two wiki's.. this can be a good thing if we like to have a separation with a users wiki and a development wiki this is bad if we like to keep things in one wiki. What do you think?
- I read MySQL and Trac is still experimental?
- Do we install Trac on the current production site? Duplicate this to the dev. site and then replace the production site with the dev. site? It's a bit strange but might be the most practical thing to do?
- Trac has admin permissions a few things, do we need to think about how to manage these permissions?
- Anything else that need some thought?

Not that everything needs to be resolved before we can get going with this, but just to make sure were not missing some important aspects that can hit us halfway trough.

[Stealth870]

I love Trac, after seeing it on the CA mod's site, and on Pidgin, I just love the way the ticket system, roadmap, and timeline features work...being able to subscribe to an RSS and get the latest updates on everything.

As for all the technical stuff, I can't really say much about that, as I don't know how difficult migrations would be. But I definitely support the use of Trac.

[AF]

I think a simple install is the way to go, putting it wherever is needed to get svn working too.

The directory structure of trac would be something Trac handles right? Like how a person doesn't dither over the directory structure of a word press install because theres little need.

As for the 'experimental' nature of mysql, I think that can be ignored as we have plenty fo examples of active stable working Trac sites using mysql.

[Tim Blokdijk]

I mean dir structure in svn, I like to put everything we use on the site in svn.
But stuff like trac and buildbot are a bit external to the site (external to the www-root dir anyway), and it only makes sense to put it in svn if we actually like to customise the installation. If we only update it and apply security fixes then it would probably be done more effective by using the package manager.

I have been reading the install instructions for trac but the quality of the documentation is a bit a hit and miss.
Who did the trac installations for http://trac.springlobby.info/ and http://www.caspring.org/ ? Maybe that person(s?) can help with this?

[BrainDamage]

springlobby is maintained by semi, while caspring is by det; i don't know about det but you should be able to find semi in the IRC channels springlobby @ freenode or taspring @ freenode

[Tim Blokdijk]

Can they just use the forum? Anyway thanks I will try to get myself on IRC.

[semi]

Hi. I run the springlobby.info server.

AF made a suggestion for Trac based management of the site. And so far everybody agrees with this. I decided to open this topic to discuss this more in-depth. I know what Trac is although I never used it in practice so I can make a wrong assumption here or there, please correct me if so.

Trac would be really practical and supplement things in a very nice way, my work (requirement analysis, development processes, tech. documentation and version history) can be moved from the odf docs to the trac wiki.
Only the roadmap is overlapping but it's (far) more practical to use Trac for that.

But there are a few practical problems that need to be discussed.
- You need root rights to install it, is this practical?

Only to install the trac package and it's dependencies. On my debian this was just a "sudo aptitude install trac libapache2-mod-python" and writing some apache config and provide some directory where the trac admin has write access. After the trac project is initialized with some other user than root, it can be configured by that user. Most of the configuration can be done through the trac web interface.

- It's a bit like buildbot that it's part of the site but still a separate application outside www-root, how should we organize the dir structure?

I have trac in /srv/trac/springlobby and static www in /srv/www/springlobby, and svn in /srv/svn/springlobby

The trac env is very much similar to svn repository in that respect, there is no point to put it under www-root.

- If we like svn integration we need to install in on Fnodia's server. This may take more time then a installation on a random server. What do we like to do?

Svn repo could be mirrored to another server. But then the main svn repo should preferably tell the mirror when there is new stuff, so that it does not need to poll. Or the mirror could just poll every hour or so. Nobody may commit to the mirror.

After the initial setup is done, there should be no need for root access and only occasional need for trac admin access, with plugins even that should mostly be possible with browser through the trac pages.

Perhaps the main svn server should be moved to somewhere where it's possible to have more admins, in case Fnordia is busy?

- Trac is doing the same job as Mantis, is it practical to move everything to Trac? Or do we only use it for the site and Mantis for the engine?

Basically trac without it's tickets is just yet another wiki, and then I don't see much reason for not using the existing wiki for developement too.

Trac ticket system is nice, and there probably is already a script to migrate all existing tickets from mantis. Someone should check if there is one.

- Trac has its own wiki, that means we will have two wiki's.. this can be a good thing if we like to have a separation with a users wiki and a development wiki this is bad if we like to keep things in one wiki. What do you think?

With heavy hyperlinking between the two, there should be just a couple downsides with having 2 separate wikis:
- need separate user accounts for both
- looks different
- what to put in each one, is a line drawn in water
- no common list of all pages
- separate maintenance for both = twice the maintenance

If there is a script to migrate all the existing pages from current wiki to trac, it would probably be a good idea to run it and drop the old wiki.

- I read MySQL and Trac is still experimental?

Springlobby.info is small, I just used the sqlite, no opinion on that.

- Do we install Trac on the current production site? Duplicate this to the dev. site and then replace the production site with the dev. site? It's a bit strange but might be the most practical thing to do?

If that means no new edits get lost in the process, I hope.

- Trac has admin permissions a few things, do we need to think about how to manage these permissions?

Give them to as many people as possible. Spring already has problems with key people being inaccessible and idle when they might be needed the most. Only avoid giving them to people who are difficult to work with.

- Anything else that need some thought?

It would be really great to see spring move to git. But git support in trac does not seem as ready, being originally made for just svn. Springlobby is on git now, and I still maintain the svn just to keep our trac running. This seems doable this far.

Not that everything needs to be resolved before we can get going with this, but just to make sure were not missing some important aspects that can hit us halfway trough.

[BrainDamage]

Trac ticket system is nice, and there probably is already a script to migrate all existing tickets from mantis. Someone should check if there is one.

uhmm, i found this: http://trac.edgewall.org/ticket/1514

it seems to be a bit experimental, but it's better than nothing i guess

[Tim Blokdijk]

Hi. I run the springlobby.info server.

Hi semi, thanks for the reply.

- If we like svn integration we need to install in on Fnodia's server. This may take more time then a installation on a random server. What do we like to do?

After the initial setup is done, there should be no need for root access and only occasional need for trac admin access, with plugins even that should mostly be possible with browser through the trac pages.

Perhaps the main svn server should be moved to somewhere where it's possible to have more admins, in case Fnordia is busy?

I would like to have a few people with root access but hosting at Fnordia is not that bad, I mean Fnordia is limited in the time he dedicates to Spring and this is a problem from time to time but he is around (via e-mail) and has been from the start of the Spring project. He has maintained the Spring site for years and knows what has happened to the data in that time. Backups are made and he is not difficult to work with in any way. I accept it if I have to wait a few weeks before he has time to do something. I mean I'm open to any other options but I'm not unhappy with Fnordia. Maybe we can move to a kvm? So shell accounts are possible without to much risk? I should ask him about that.

- Trac is doing the same job as Mantis, is it practical to move everything to Trac? Or do we only use it for the site and Mantis for the engine?

Basically trac without it's tickets is just yet another wiki, and then I don't see much reason for not using the existing wiki for developement too.

Trac ticket system is nice, and there probably is already a script to migrate all existing tickets from mantis. Someone should check if there is one.

I have been looking at Mantis development and the new upcoming release will have MediaWiki integration and a roadmap feature like trac.. Manis is php based, which fits nicer with the rest of the site.
Maybe we should look into this to?

- Trac has its own wiki, that means we will have two wiki's.. this can be a good thing if we like to have a separation with a users wiki and a development wiki this is bad if we like to keep things in one wiki. What do you think?

With heavy hyperlinking between the two, there should be just a couple downsides with having 2 separate wikis:
- need separate user accounts for both
- looks different
- what to put in each one, is a line drawn in water
- no common list of all pages
- separate maintenance for both = twice the maintenance

If there is a script to migrate all the existing pages from current wiki to trac, it would probably be a good idea to run it and drop the old wiki.

If we move to Trac then I would like to integrate MediaWiki into Trac if possible (redirecting wiki links to the existing MediaWiki installation).
It saves us a migration.

- Trac has admin permissions a few things, do we need to think about how to manage these permissions?

Give them to as many people as possible. Spring already has problems with key people being inaccessible and idle when they might be needed the most. Only avoid giving them to people who are difficult to work with.

I will think about some objective criteria for people that can and can't become admin (something like a forum poll or so).

- Anything else that need some thought?

It would be really great to see spring move to git. But git support in trac does not seem as ready, being originally made for just svn. Springlobby is on git now, and I still maintain the svn just to keep our trac running. This seems doable this far.

I'm fine with anything that works ok, svn works ok so I use it but I don't have any special attachment to it.

[AF]

I agree, keeping everything in php would be nice, and if the next mantis has all these features its a simple upload and run upgrade script process for the most part.

Is there a test environment we can look at for the next mantis builds?

[Tim Blokdijk]

http://www.futureware.biz/mantisdemo/
A demo site, I can login with user "test" password "test".
Take a look at http://www.mantisbt.org for the rest.

[AF]

Its a big bowl of ugly.

I say we use trac for the site development and continue using mantis.

If Trac turns out to be better than sliced bread we should switch.

If the updated mantis comes out on top we switch site back to mantis and nothing changes.

The trac wiki would be best for maintaining the trac site with any wiki type usage going on in the media wiki install.