Hi Paul,

There's no need to play it like Trac is the only tool that does all this
stuff.

Bugs can be tied to changesets with Mantis - check the scmbug project on
freshmeat and also read the Mantis mailing lists. Even a quick perl cvs
commit script would do the trick for that. Ditto wikis - I have seen
patches for MediaWiki that will create links to Mantis as well.

Trac is a tool which ties all this together with a ribbon and it looks
very slick, but it's young and still lacks many features which the more
mature tools offer. Sourceforge has tools to allow you assess the
activity of a project - there are statistics graphs, release histories,
project ranking, mailing list calendar view (none of which Trac do),
plus View CVS logs,and bug and RFE tracking. Again this comes back to
the timeline feature which is cute but is only a small thing in the big
picture of what all these various provide. SF's features are more
complete and it is a major player and the first place you go when you're
looking for an open source project that you hope exists.

I'm happy to stick with the whole Trac thing if that is the group
consensus. But it's not the only good option out there and we don't need
to pretend that is. We just have to agree to use it.

JP

Paul Baranowski wrote:

>Nenad Pandzic wrote:
>
>
>>The problem is that I had oportunity to use some other project's (for example
>>FCKeditor) forums, bug and patch tracking on Sourceforge and was pretty
>>satisfied. I've registered Campsite on Sourceforge in 2002 and at that time
>>Sourceforge pretty sucked. But that's not true anymore.
>>
>>I simply don't see so big Trac benefits over Sourceforge tools which could
>>neutralize all those costs in time and money needed for its installation,
>>hosting and maintenance. Not to mention time needed to learn how to use it.
>>
>>Very simple. Just a cold calculation. No emotions.
>>
>>
>
>Your calculation is based on a formula that feels right for you. And
>the formula seems to be optimizing for "immediate cost savings". If you
>would like to talk about cost savings, then you have to look at TCO
>(total cost of ownership). There are also intangibles to be taken into
>account: transparency in the development process, documentation, ease of
>use, and communication.
>
>Please take a look at the campsite Trac homepage:
>http://code.campware.org/projects/campsite/
>
>Trac shows you two very important things that sourceforge does not: what
>has been happening (timeline), and how far along the current release we
>are (roadmap). You can also see the bugs/features by milestone, showing
>you when each feature will be implemented. Do you need these things?
>Maybe not. What about someone coming in to see if anything is happening
>with the project? Yes. What about someone in the management who wants
>to see what has been happening? Yes. Do they want to read the email
>lists? No.
>
>How do you know what's happened recently on a project if you use
>sourceforge? Maybe read the mailing lists, maybe scanning through the
>bugs, maybe emailing the mailing list with a question...or the best way
>would be reading a document that someone has written about the current
>status. Writing/updating this document or answering these emails will
>take time. This time needs to be incorporated into the TCO for sourceforge.
>
>Trac also matches tickets to changesets, something infinitely valuable
>when you want to review someone's checkins. Otherwise you have to
>manually go through and do all the diffs manually. This is so
>time-consuming that usually I dont even do it. This time, across all
>developers, would have to be incorporated into the sourceforge TCO. You
>also have to take into account the intangible of the increased
>code-review process that is possible using trac.
>
>And then there's the wiki, which doesnt exist on sourceforge, which we
>would have to set up anyway. This would also have to be taken into
>account for the sourceforge TCO.
>
>- Paul
>
>
>
>

------------------------------------------
Posted to Phorum via PhorumMail