Noah Kantrowitz kirjoitti:
>>
>> First, I'd like to say that I've been using Trac for 3 years, I like
>> Python and Trac very much.
>>
>> Today, I read a post in which a project migrated to Redmine so I
>> decided to take a look at it. Clearly, Redmine is a Trac clone with
>> some nice features added. Quite interesting features, I admit.
>>
>> What I'd like to ask is why Redmine has became a better Trac so fast
>> and Trac evolution is so slow? Is it a management problem? Too many
>> endless discussions about go-no-go feature?
I wouldn't say that Redmine is better. But it has some nice features
that Trac don't provide.
I mainly use still Trac but one latest project required some features
that I got from Redmine OOTB so I used it for that. Also now it used as
showcase would it be switchover...
I'll list here things I found while (I got payed evend payed for by
customer) to research Trac (or any other) tool to fit their and our
requirements.
Requirements for project I chose Redmine over Trac were 'simple':
- Project will have four different 'subprojects':
* spesification, design, implementation and testing.
- Three user roles:
* Management
- read/write to everything
- management of user and roles with ease
* Customer
- read to specs and design, read/write to testing
* Developer
- read/write to everything
- User interface in Finnish
> Let's be clear on what Redmine is an isn't. It is clearly at least inspired
> by Trac in most areas, and downright copies the UI in others.
And if you look latest enhancement requests there is quite load of
Trac-like repository browsing upcoming... :D
Look and feel of Redmine is somehow... Um.. Amateur compared to Trac.
Trac looks and feels more "professional".
In Redmine you need to do lot's of clicking and navigation around system
is not that straightforward - part of that complexity comes from
multiprojecting. And sometimes it's very easy to get lost in what
project you are and such.
Only really good thing in Redmine is user management. There is very
clear userprofile and notifications and some customizations are really
user or user role centric (like ticket notifications, workflows and such).
> It does add
> many features people request frequently, however in many cases it does this
> in a way that forces you to use their project management ideals. An example
> I am far too familiar with is "multiple project support". This has been an
> open request in Trac for a very long time (#130 has been around for 4
> years). Most people find it insane that we haven't implemented this feature.
In Redmine this multiproject means merely one sublevel (not deeper)
projecting which just can aggregate tickets (issues in their terms) to
main project. But nothing more. They don't share anything else in
common. It's just one solution and not even good one.
> The problem is that if you ask 10 different people what they actually want
> from multi-project support, you get 10 different answers.
More than true.
> Trac has always
> made it its mission to stay out of the way and allow the development to team
> to use whatever processes they wish.
And succeeds in that pretty well.
> Adding a "project" column to every
> table, and adding a global filter to all queries would be easy, but this
> covers only a small number of the actual multi-project use cases. Designing
> good, generic solutions to these problems takes time and thought, a lot of
> both.
But still it feels that there is not much of real discussion how to
implement and possible solutions. Most of requests are bypassed by "use
a plugin" or "do a plugin" statements. It's a bit annoying specially
since it makes you feel that you need to trust some hacked "3rd party" tool.
> We do move much slower than many other FOSS projects, however this has
> the upside of producing generally very high quality code, etc. There is a
> definite desire to not include hacky solutions just to add another bullet
> point on a list somewhere.
Well I wouldn't agree here. Many FOSS projects are stalled etc. Only
very few can manage with decent release cycles - and usually it means
that there is people who gets money from doing project.
Also I know that 0.11 brought very large changes, specially change of
templating system is something that can't be done overnight.
Hopefully pace will raise a bit in the future...
> If you happen to like the Redmine methodology,
> then by all means use it, but don't assume everyone feels the same way.
> There are other aspects of Redmine in particular I can go off on a tangent
> about (hint: their plugin system is shameful), but really what I said is the
> important part.
Agree on that plugin system. It's very shameful but there seems to be
upcoming some improvements to that.
Also wiki is way weaker than Trac and overall feeling is, as stated at
the beginning - amateur class.
> If you want a Trac that does all of these kinds of
> "standard" things, you are welcome to wait until 1.0. In the meantime we
> will continue to do our best building a solution that everyone can use and
> that fits our mission statement.
Is is really necessary to wait for such a long time (At current pace it
would mean about 89 upcoming releases, each one in about 14 months.. :D)
to get things done?
IIRC there has been few suggestions to have some of the most popular
plugins to be part of "core", or at least distributed with core.
(Darn. Long post. Hopefully this made any sense)
I'm still in favor of Trac. Redmine has potential but it takes while.
Specially since there is not really way to expand Redmine like you can
do with Trac.
--
Jani Tiainen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
