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,
--
Bil Kleb
http://fun3d.larc.nasa.gov
Bil Kleb wrote:
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.
--
Posted via http://www.ruby-forum.com/\.
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
On Dec 21, 2006, at 12:55 PM, Bil Kleb wrote:
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
---
Uma Geller
Bil Kleb wrote:
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 wrote:
I recently read that the Rails-based alternative, Collaboa
(http://collaboa.org/\) is on the move again, but I can't
even see code.
Searching collaboa-talk mailing list, I have found conversation about an
collaboa fork:
http://lists.collaboa.org/pipermail/collaboa-talk/2006-December/000463.html
It led me to the http://www.retrospectiva.org
I have tried retrospectiva and It seems me quite usable and features
rich.
Regards,
Ernad
--
Posted via forums.bring.out.ba.
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 ;(
--
Posted via http://www.ruby-forum.com/.
Michael Greenly wrote:
Bil Kleb wrote:
[..] 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,
--
Bil Kleb
http://fun3d.larc.nasa.gov
James Edward Gray II wrote:
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
http://funit.rubyforge.org
Uma Geller wrote:
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,
--
Bil Kleb
http://fun3d.larc.nasa.gov
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 Edward Gray II wrote:
On Dec 21, 2006, at 12:55 PM, Bil Kleb wrote:
> 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
Michael Greenly wrote:
Bil Kleb wrote:
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.
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
Uma Geller wrote:
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 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
Trans wrote:
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,
--
Bil Kleb
http://fun3d.larc.nasa.gov
Ernad Husremović wrote:
Searching collaboa-talk mailing list, I have found conversation about an
collaboa fork:
http://lists.collaboa.org/pipermail/collaboa-talk/2006-December/000463.htmlIt led me to the http://www.retrospectiva.org
Very nice; thank you.
So, is the original branch still active?
Thanks again,
--
Bil Kleb
http://fun3d.larc.nasa.gov
Ernad Husremović wrote:
It led me to the http://www.retrospectiva.org
I have tried retrospectiva and It seems me quite usable and features
rich.
Many thanks! Retrospectiva is currently under heavy development. I hope
to able to release 1.0RC1 soon, but I need some more help with testing
(stability is a key goal of Retrospectiva). Please check the website for
announcements and further infos.
Dimitrij
--
Posted via http://www.ruby-forum.com/\.
[snip]
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.
On 12/21/06, Marc Heiler <shevegen@linuxmail.org> wrote:
--
Simon Strandgaard
http://opcoders.com/
evanwebb@gmail.com wrote:
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,
--
Bil Kleb
http://fun3d.larc.nasa.gov
Bil Kleb írta:
Trans wrote:
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.
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
e-mail: parragh@dayka.hu
web: parszab.nir.hu
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
On 12/22/06, Bil Kleb <Bil.Kleb@nasa.gov> wrote:
Trans wrote:
>
> 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.