Work? What work?
So, just a brief update. I’ve recently (a few months back *cough*) taken over our Linux “education” group at work, and it’s interesting. The sad part is, we mostly only see people who already knows what Linux is as we’re working internally in a world where most people are rather Computer savvy as it is. It’s given me a few new viewing angles though, and I’ll get back to that at a later point.
Currently working on some Trac guidelines for our Change Management process as well. Working from home today to actually get something done with it, as most of the days I wind up getting too many disturbing calls, talks and discussions to be very efficient. Our first two tries at making a decent workflow winded up a bit messy, and I think we really must get this down properly this time.
There are some other things I react on, and want to fix, for example, as it looks now, every single project sets up their own bugtracking/ticketsystem, and every project uses a different system (trac, mantis, clearcase, dimensions, etc). Preferably, this should be centralized in some fashion, and if possible I’d love to get a bit more homogenized environment. As it is, I try to tell people “look, here’s a system for handling your day to day tasks, use it!”. First time, the workflow got overly complex, second shot was also overly complex, and people where put off by all the choices and steps to take. This problem mainly stems from project/change management criterion.
My latest and greatest (yeah yeah) workflow should alleviate some of these problems by making some of the choices less visible to normal users. Ie, we have one task management system and a problem and change management system baked into one, but normal users (programmers) only use the task management system, while the project manager, tech project manager and CM also have the ability to handle problems and changes in separate workflows.
We’re also adding the ability to have supertickets, where a single problem report can contain several tasks. This is a pseudo development so far, as we’re not actually adding the whole deal right now, we’re just adding the idea of it, not bounds checking or views/reports of it. Basically, every ticket can have a superticket (we add a numeric field to the ticket), which can point to another ticket, which is the “parent” ticket. This makes it possible to handle a large and complex bug in several smaller tickets. Anyways, the idea is there, but it’s not fully implemented. If our management likes it, and the others like it, we could implement it for future usage. I’m worried it’s too complex however. At the same time, one complex system might be better than 6 alltogether different systems as it allows for longer time to learn? Kind of like… well, unix for example. Once you find ls, its a darn good bit faster than having to click your way through a whole heap of paths to find the specified file list.
At the same time, both me and PM are a bit tired of Trac’s shortcomings, maybe change to Mantis for example? My general thought to this however is, we need to stick it out i’m afraid… one more system will just make the normal user less interested in the new tool and hence taking even longer to learn. As it is, people use it at a bare minimum cause they dont know it, give them time to learn it properly, and they might come to like it. Comments on this line of thinking?
For now, tata. Back to writing.
Trac on separate server from subversion
Filed under: Configuration Management, Windows
#!/bin/sh
SVNSYNC=/usr/local/bin/svnsync
$SVNSYNC synchronize URL_TO_MIRROR_REPO –username=svnsync –password=svnsyncpassword &
exit 0
Trac on windows
Trac is a rightfull bitch to install on win32 as it requires very specific version matching of packages. This is a long winded installation note with the more or less latest versions available as of this writing.
I’m hoping to get working on TortoiseSVN and Trac integration once this is done (ie, make tortoise automatically set variables etc sent in change notes, which can hence update the issue tracking systems in trac and so forth. The way of working is really really sweet imho, and I think it could be a really nice way of working. I’m just sad that I have to set all this serverstuff up on windows though.
Let’s begin with a list of all the installation files used:
WampServer2-APACHE229.exe
svn-win32-1.5.2.zip
mod_python-3.3.1.win32-py2.5-Apache2.2.exe
These packages should be fairly simple to get started with. Install them straight on, in the order mentioned.
Unsupported version control system “svn”
For an Apache server here’s the essentials:1. Copy bin/mod_dav_svn.so and bin/mod_authz_svn.so to the Apache modules directory.2. Add the Subversion/bin directory to the SYSTEM PATH.3. Edit the Apache configuration file (httpd.conf) and make the following changes:3a. Uncomment the following two lines:
#LoadModule dav_fs_module modules/mod_dav_fs.so#LoadModule dav_module modules/mod_dav.so3b. Add the following two lines to the end of the LoadModule section:LoadModule dav_svn_module modules/mod_dav_svn.soLoadModule authz_svn_module modules/mod_authz_svn.so3c. Add the following to end of the file.<location /svn>DAV svnSVNPath c:\projects\svn\testAuthType BasicAuthName “My Subversion repository”AuthUserFile “c:\projects\svn\test\conf\passwd” Require valid-user</location>
<location /mpinfo>
</location>
<Location /trac>
</Location>