Ruby's Trac Alternative

[Bil Kleb]

So I'm trying to use Trac for our FUN3D development,
as an experiment for a potential NASA-wide installation,
but Trac is not the easiest thing to get setup. Lately,
I've even had to hack some of the Python internals to
get syntax highlighting working via enscript.

I recently read that the Rails-based alternative, Collaboa
(http://collaboa.org/) is on the move again, but I can't
even see code.

What's up?

Thanks,

 

[Michael Greenly]

So I'm trying to use Trac for our FUN3D development,
as an experiment for a potential NASA-wide installation,
but Trac is not the easiest thing to get setup. Lately,
I've even had to hack some of the Python internals to
get syntax highlighting working via enscript.

I recently read that the Rails-based alternative, Collaboa
(http://collaboa.org/) is on the move again, but I can't
even see code.

What's up?

Thanks,

What system were you installing this on? I've always found Trac very
easy to setup and stable to use.

 

[James Edward Gray II]

So I'm trying to use Trac for our FUN3D development,
as an experiment for a potential NASA-wide installation,
but Trac is not the easiest thing to get setup. Lately,
I've even had to hack some of the Python internals to
get syntax highlighting working via enscript.

You are definitely right that it's a pain. Everyone pretty much
tolerates it though, because it is definitely the best of the best.

I recently read that the Rails-based alternative, Collaboa
(http://collaboa.org/) is on the move again, but I can't
even see code.

I've seen many want-to-be-Trac programs. None of them go the
distance, sadly. When I last looked at Collaboa it didn't have or
even plan to include a wiki. That kills it as a Trac replacement for
me.

And really, is Rails deployment much better than Trac deployment?

James Edward Gray II

 

[Bil Kleb]

[..] Trac is not the easiest thing to get setup.

What system were you installing this on? I've always found Trac very
easy to setup and stable to use.

$ uname -romv
2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:29:47 EST 2005 x86_64 GNU/Linux

$ cat /etc/redhat-release
Red Hat Enterprise Linux WS release 4 (Nahant)

Actually, I'm living vicariously through my SA, except
for the having to hack Python part -- I'm enduring that
part.

Regards,

 

[Marc Heiler]

Oh yeah...

I'd love to see something like Trac in Ruby too

But I guess it will still take some time, dont even
know if porting Trac-python into Ruby would be as
easy ;(

 

[Uma Geller]

So I'm trying to use Trac for our FUN3D development,

as an experiment for a potential NASA-wide installation,
but Trac is not the easiest thing to get setup. Lately,
I've even had to hack some of the Python internals to
get syntax highlighting working via enscript.

For the Python-clueless in me, it wasn't easy to set-up Trac.
But after the initial pain things went rather smoothly.

I agree the ideal situation would be one were we could hack and add
qualities to the tool (I'm always finding names for things, Rutrac,
Tracby ?) but it seems so far, the quality of Trac has largely
outweighed the pain of being subject to Python.

Is it the main reason for a port would be to eliminate the pain of
hacking in Python, or is it something else we would be able to do with
Ruby that is (near) impossible with Python ?

A lady will always prefer gems to snakes, of course, but I'm trying to
find out whether there are powerful reasons to port Trac so that the
Ruby community would be willing to throw its weight behind.
Otherwise, solo efforts may not be the best idea for this kind effort
with little or no noticeable reward.
(in the end you will just have something that looks and smells like
Trac, only with Ruby inside)

best,
UG

 

[Simon Strandgaard]

I'd love to see something like Trac in Ruby too

[snip]

+1

installing bugzilla wasn't easy.
installing trac was relative easy to install.

<braindump>
trac has a few issues:
1. no markdown.
2. no checkbox for enabling syntax coloring.
3. repository browser lacks diff.
4. inline image ackward.
5. no time planning.
6. not easy to extend, I don't do python
</braindump>

besides that trac is very good. but a rubytrac would be even better.

 

[Bil Kleb]

You are definitely right that it's a pain. Everyone pretty much
tolerates it though, because it is definitely the best of the best.

Offline, someone pointed me at Thoughtworks' Agile on a disk:

http://buildix.thoughtworks.com/

The trouble with this shrink-wrapped approach is that in the event
that we eventually expand to a whole series of projects, like Why's
little bevy at http://code.whytheluckystiff.net, we need more hands-on
experience with the inner workings of the beast itself. Then again,
I'm probably mistaken.

When I last looked at Collaboa it didn't have or even plan to
include a wiki. That kills it as a Trac replacement for me.

Ditto. Just slamming in Junebug <http://junebugwiki.com> or
something similar would be enough for me.

Later,

 

[Bil Kleb]

Is it the main reason for a port would be to eliminate the pain of
hacking in Python, or is it something else we would be able to do with
Ruby that is (near) impossible with Python ?

Irrespective of Brooke's Second System Syndrome, I'd just like
a greenfield approach, incorporating the lessons learned from
Trac with the easy of `gem install` and the simplicity that is
Camping or Rails application code (not the underlying framework).

A lady will always prefer gems to snakes, of course, but I'm trying to
find out whether there are powerful reasons to port Trac so that the
Ruby community would be willing to throw its weight behind.

It sounds like Collaboa has had some recent influx of love,
but after 22 days of silence, I'm beginning to wonder what's
going on.

Regards,

 

[evanwebb]

I have an experimental version of collaboa I've been hacking on this
week that adds a wiki and timeline support.

I plan on giving the patch to add both of these back to the collaboa
and if they don't want it, I'll maintain it seperately. I adore the
wiki integration with the ticket and SCM system. But I didn't want to
have to hack python when I wanted to change something. Collaboa is
pretty simple and adding the wiki and timeline have been pretty simple
so far.

- Evan Phoenix

 

[James Britt]

What system were you installing this on? I've always found Trac very
easy to setup and stable to use.

Same here. Well, after all the fsck'n Python dependencies are in place.


But I've had more issues installing svn than Trac.


I've started assembling some Ruby helper scripts for certain tasks
(creating a new Trac project; modifying user permissions) but still find
Trac best-of-breed.

But it's been a while since I've looked at Collaboa (which, at the time,
was a poor runner-up to Trac).

(Trac + darcs would be sweet, but as far as I can tell it is only really
doable through an svn-sync hack.)

--
James Britt

http://www.ruby-doc.org - Ruby Help & Documentation
http://beginningruby.com - Beginning Ruby: The Online Book
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[James Britt]

For the Python-clueless in me, it wasn't easy to set-up Trac.
But after the initial pain things went rather smoothly.

I recently installed Trac on CentOS 4.something; never saw a lie of
Python. Used yum. (Figuring out how to use yum for this was a tad
annoying ... )

I agree the ideal situation would be one were we could hack and add
qualities to the tool (I'm always finding names for things, Rutrac,
Tracby ?) but it seems so far, the quality of Trac has largely
outweighed the pain of being subject to Python.

Done much Python? Where's the pain?

Really, unless you're writing an app, hacking Python here and there is
not far from hacking Ruby. (Assuming your editor is correctly
configured for the static indentation.)

Is it the main reason for a port would be to eliminate the pain of
hacking in Python, or is it something else we would be able to do with
Ruby that is (near) impossible with Python ?

A lady will always prefer gems to snakes, of course, but I'm trying to
find out whether there are powerful reasons to port Trac so that the
Ruby community would be willing to throw its weight behind.

I've acquired a fondness for DokuWiki, WordPress and TextPattern.

That's right: P fuckin' HP apps.

Why? Because I rarely need to actually look at code. And when I do,
it's trivial to do what I need. But, fortunately, that's not very often.

Sometimes (well, often) I roll my own apps because I want to hack on
something while exploring, because I'm not exactly sure what I want it
to do, and I want to get it Just Right for James. That's why I wrote my
own blogging software. That's why I wrote my own application deployment
suite. That's why I wrote my own publishing tool.

But other times I just want the app to get out of the way. It's nice
when something is written in Ruby, but if looking at its source code is
*not* what I really want to be doing, then it's a moot point.

My blogging software is great for me, but not my niece; WordPress means
she can do great stuff without learning Ruby. It's a Web appliance.
Same goes for Trac. I've made some tweaks using OPC (other people's
code); snake-handling is kept to a minimum, and Trac simply lets me
focus on what I want to do: manage my own Ruby projects.

Otherwise, solo efforts may not be the best idea for this kind effort
with little or no noticeable reward.
(in the end you will just have something that looks and smells like
Trac, only with Ruby inside)

Then more people will be hacking on Trac and fixing its bugs and writing
plug-ins than they will for RuTrac (or whatever), simply because Trac
has the critical mass for that feature set.

I know people writing project management tools in Ruby, but they're
doing it because they *don't* want Trac; they're scratching an itch.

That said, I have been writing Ruby tools that treat WordPress, Trac
etc. as black boxes of behavior. (Maybe one day I'll get around to
releasing my Tracula project. )

I don't usually like re-inventing too many wheels, but pimping out the
ride is OK.


--
James Britt

http://www.ruby-doc.org - Ruby Help & Documentation
http://beginningruby.com - Beginning Ruby: The Online Book
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[Bil Kleb]

I have an experimental version of collaboa I've been hacking on this
week that adds a wiki and timeline support.

Neat!

Hopefully, the Collaboa site will come to life again and
be able to incorporate it.

Regards,

 

[Trans]

So I'm trying to use Trac for our FUN3D development,
as an experiment for a potential NASA-wide installation,
but Trac is not the easiest thing to get setup. Lately,
I've even had to hack some of the Python internals to
get syntax highlighting working via enscript.

I recently read that the Rails-based alternative, Collaboa
(http://collaboa.org/) is on the move again, but I can't
even see code.

What's up?

I think there is a tendency to overestimate tools like Trac. I did so
myself for a long time until I released that just by organizing my
project's folder in special way it could used as a project web app in
itself. It's nice just to mix and match stand-alone components for the
purpose.

T.

 

[Bil Kleb]

I think there is a tendency to overestimate tools like Trac.

Indeed, as the http://agilemanifesto.org says,

Individuals and interactions over processes and tools

but for a team of 12 under a posse of project managers,
Trac is a necessary evil. And when you approach tens
of teams and whole organizations worth of project managers,
Trac looks gossamer thin.

Regards,

 

[Parragh Szabolcs]

Bil Kleb írta:

Indeed, as the http://agilemanifesto.org says,

Individuals and interactions over processes and tools

but for a team of 12 under a posse of project managers,
Trac is a necessary evil.

Just to let a counter-opinion be heard as well: We have used Trac for
many projects, averaging 3-7 developers, and it has been a great help
and an enormous help.

 

[Parragh Szabolcs]

Parragh Szabolcs írta:

Just to let a counter-opinion be heard as well: We have used Trac for
many projects, averaging 3-7 developers, and it has been a great help
and an enormous help.

meaning: great tool, and an enormous help

 

[Martin DeMello]

Indeed, as the http://agilemanifesto.org says,

Individuals and interactions over processes and tools

but for a team of 12 under a posse of project managers,
Trac is a necessary evil. And when you approach tens
of teams and whole organizations worth of project managers,
Trac looks gossamer thin.

Personally, our startup (10 people at the moment) has been a lot
happier since we moved from Trac to Bugzilla + Mediawiki. I can't
remember the specifics, but Trac simply lacked some features our QA
lead was used to from Bugzilla, and it was too much of a pain to try
and see if we could find a third party plugin that implemented them.

On the other hand, Trac was very quick and easy to set up, and got us
off the ground with minimum effort. I wouldn't have wanted to start
off using Bugzilla.

martin

 

[Rob Sanheim]

Personally, our startup (10 people at the moment) has been a lot
happier since we moved from Trac to Bugzilla + Mediawiki. I can't
remember the specifics, but Trac simply lacked some features our QA
lead was used to from Bugzilla, and it was too much of a pain to try
and see if we could find a third party plugin that implemented them.

On the other hand, Trac was very quick and easy to set up, and got us
off the ground with minimum effort. I wouldn't have wanted to start
off using Bugzilla.

martin

We are using Trac right now (4 developers, ~10 biz people), and its
working well so far. The only thing I miss is having a way to attach
estimates to tasks, whether it be "points" in the xp sense or just
hours. I know it can be done with custom fields in Trac, but just
haven't looked into the details. The SVN integration is very nice.

Bugzilla may be powerful, buts its UI is just so horrid that I dread
using it. It definitely feels like the interface was developed by
programmers who just wanted to throw every field and option onto the
screen, with no regard to usability. For the vast majority of items,
you just don't need to mess with 20 fields to enter a to-do item - so
why not hide them behind an "advanced" link?

- Rob

 

[Martin DeMello]

Bugzilla may be powerful, buts its UI is just so horrid that I dread
using it. It definitely feels like the interface was developed by
programmers who just wanted to throw every field and option onto the
screen, with no regard to usability. For the vast majority of items,

Reminds me of the classic http://www.jensroesner.de/wgetgui/

martin