Is Redmine a better Trac? What's gone wrong with Trac?
andre...@gmail.com
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?
Regards,
André
Noah Kantrowitz
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. 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.
The problem is that if you ask 10 different people what they actually want
from multi-project support, you get 10 different answers. 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. 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. 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. 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. 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.
--Noah
Jani Tiainen
>>
>> 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
Jeroen Ruigrok van der Werven
> - User interface in Finnish
I'm still waiting for your messages.po for Finnish. :)
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
With a nuclear fire of Love in our Hearts, rest easy baby, rest easy...
Jani Tiainen
> -On [20080619 10:11], Jani Tiainen (red...@gmail.com) wrote:
>> - User interface in Finnish
>
> I'm still waiting for your messages.po for Finnish. :)
I thought that you were about to translate it yourself.. :D
Well we've having our boozing holidays (that funny midsummer party) so I
think I can pay a bit of attention to that translation... :D
I've just been waiting for 0.11...
--
Jani Tiainen
Erik Bray
>
> > -----Original Message-----
> > From: trac...@googlegroups.com [mailto:trac...@googlegroups.com] On
> > Behalf Of andre...@gmail.com
> > Sent: Wednesday, June 18, 2008 4:35 PM
> > To: Trac Development
> > Subject: [Trac-dev] Is Redmine a better Trac? What's gone wrong with
> > Trac?
> >
> >
> >
> > and Trac evolution is so slow? Is it a management problem? Too many
> > endless discussions about go-no-go feature?
>
> 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. 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. 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.
>
Exactly--we stick with Trac because we can fairly easy make Trac do
what we want for our needs. (Nevermind other issues like RoR being
annoying). If we used Redmine we'd have to do most everything there
way, and that might be fine for some people, but we have lots of
special needs and requirements that would be a HUGE pain in the ass to
implement in anything less flexible than Trac
Erik
Jeff Hammel
> > 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.
I'd just like to add for my money that I don't think of "3rd party" plugins as hacky solutions for making trac instances behave as desired. I think as a means to this end, trac + plugins work very well. Admittedly, this is from the perspective of a developer that doesn't mind getting his hands dirty investigating, writing, and installing plugins to build the trac that I and my coworkers + clients want. Trac isn't quite to the point where someone without expertise in this area can click on a button and install trac with completely intuitive configuration, though it seems to be moving in that direction. I think the existing model (correct me if I'm wrong, I'm fairly new to the developer side of trac) of writing a plugin and staging it (or parts of it) for core integration is a good model, as it allows much experimentation and shake-down to generalize the plugin to the diversity of needs, and also allows for different implementations in the case where opinions and needs different.
While I'm in the boat that it would be awesome to have an intuitively buildable and configurable trac, which i think will eventually be possible (I'm optimistic as to when), for right now I would choose flexibility and a good component architecture over doing (e.g.) multiple projects out of the box. But those are my needs and I willingly acknowledge that I try to use the right tool for the job. For my job, this is trac. For others, could be something else.
jeff
Noah Kantrowitz
> From: trac...@googlegroups.com [mailto:trac...@googlegroups.com] On
> Behalf Of Jani Tiainen
> Sent: Thursday, June 19, 2008 1:11 AM
> To: trac...@googlegroups.com
> Subject: [Trac-dev] Re: Is Redmine a better Trac? What's gone wrong
> with Trac?
[snip]
> 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.
This is true. We do avoid discussion of some things when we know there won't
ever be a clear way forward without action. In the example of multi-project
support, I have been quite vocal that people should build examples of lots
of different models, and see which ones people like. This is why I have
spent so much time trying to build TracForge.
Unrelated to this is the idea that doing things in plugins is bad. I really
don't understand where people get this idea. Trac is already just a plugin
framework, and some bundled plugins (wiki, tickets, timeline, etc). There is
no fundamental difference between 3rd party stuff from trac-hacks, and Trac
itself (other than decoupled release dates, smaller codebase, etc). I wrote
a long rant on this on my blog
(http://coderanger.livejournal.com/23087.html) so I don't feel I need to
repeat it all here, but the short of it is that people need to stop thinking
"plugin" == "bad".
[snip]
> 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?
1.0 is not just the version past 0.99, it is a statement that we feel Trac
is really "stable". Not so much from a normal doesn't-crash-and-eat-data
perspective, but in terms of API and feature stability. This is similar to
how the Subversion project treated 1.0. That was the point they felt their
growing pains were over and they were ready to make promises about APIs and
system integrity. I don't really know when this will arrive for Trac, but I
am at least content that we have been moving in that direction fairly
steadily.
> 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.
Yes, when it becomes clear the plugin isn't just additional niceness, but is
making up for core deficiencies or is just so widely used that we can't
ignore it. This is why WebAdmin has been integrated into core, and some
others will likely follow it soon. TicketDelete is an obvious candidate, as
is WikiRename, IniAdmin, and parts of AccountManager. There are also plugins
that will probably not be simply included in Trac, but I am certainly
keeping an eye for possible API or UI stealing (BatchModifyPlugin and
AnnoucerPlugin come to mind). Mostly it is a matter of someone putting in
the time to integrate the feature cleanly and make sure the UI for it fits
nicely.
--Noah
Robert C Corsaro
It would be good to get feedback about why ppl feel this way. Noah has
talked about trac-hacks++ and a nice plugin installer. That would go a
long way to dispel the notion that "trac-hacks" are bad. I also think
some marketing could go a long way, like drop the name for something
more "stable" sounding. ;) A rating system would be nice, so you could
see right away what plugins are solid and widely used and which ones to
be wary of. Also, a simple way for ppl to contribute to plugins. I
think github does an excellent job in this regard and would like to see
something like that for trac-hacks. We wouldn't have such a problem
with orphaned plugins either.
What are ppl's feelings about this?
Endre Bakka
I introduced Trac to my company last fall. One of the main reasons for
going with Trac was the active and dynamic development community, and the
development philosophy. However, after following the development and
interacting with the community, I am a bit disappointed.
> In the meantime we will continue to do our best building a solution that
> everyone can use and that fits our mission statement.
From the Trac webpage:
"The mission of the project is to develop and improve the Trac program as
a collaborative effort in a bazaar-type project environment."
And it has a great link to "The Cathedral and the Bazaar". Read it. Read
it again. Then change the way you work or change your mission statement
(I'm hoping for the first solution).
Trac has a large userbase of which most are developers. There are plenty
of users willing to chip in and help take Trac to the next level. Just
look at the number of plugins. Just look at the number of patches attached
to various tickets.
Unfortunately, most of these eager users are ignored.
Example: Just two weeks ago, Jeff Hammel asked about including
AutoQueryPlugin into the core, and he listed excellent reasons why it
should be included (I agree with all of them). Nobody answered his e-mail.
Example: I wrote a patch for subcomponents since our company need this. It
was ignored, both the ticket and an e-mail. I started asking around on IRC
and was told it was clean, but way too large to include in the core so I
should make a plugin.
It took me a couple of evenings to implement, and 90% of the time was
spent trying to understand the Trac codebase so I was suprised when told
it was too big (btw, "very high quality code" should be easy to read and
understand - I think Trac still has some potential in that respect). Well,
I wrote the plugin, but it was not a pleasant experience. It was much
harder to write, uglier, required a plethora of hacks due to shortcomings
in the plug-in API, but I managed. I figured I would wait until 0.11 was
released in case last minute changes affected my plugin. I've been waiting
since December.
If I had gotten at least some feedback (even "your code sucks, clean it
up"), you would have seen many more patches from me.
Suggestions:
- Live up to your mission statement. Do it the Bazaar way (see book for
details)
- Spend a bit less time on development and a bit more time at looking at
other peoples patches that could be included. If you do, Trac will move
forward at a much higher pace. Users will be encouraged and more people
will join and write patches to include.
Add functionality in baby steps. Some crappy support is better than zip,
zilch, nothing. Users can give feedback (even in the form of patches) as
you go along steering you towards a better product. Nobody (maybe except a
handful in the world) are able to design and write the perfect system
without a couple of iterations. Everything can be rewritten (with a proper
testsystem, without fear), and database tables can be altered anyway you
like during an upgrade.
There is a reason why so many "other FOSS projects" work this way. It is
more efficient. It is the Bazaar way.
Happy hacking.
Best regard,
- Endre
Disclaimer: I just watched Linus do a Google talk on git, so my statements
are probably both bolder and harsher than they normally would be.
Noah Kantrowitz
> with Trac?
[snip]
> Example: Just two weeks ago, Jeff Hammel asked about including
> AutoQueryPlugin into the core, and he listed excellent reasons why it
> should be included (I agree with all of them). Nobody answered his e-
> mail.
Lately we have been slightly more focused on final testing before getting
0.11 out the door. I do agree that feature should be added, in fact I
thought it already was when I read the description.
> Example: I wrote a patch for subcomponents since our company need this.
> It
> was ignored, both the ticket and an e-mail. I started asking around on
> IRC
> and was told it was clean, but way too large to include in the core so
> I
> should make a plugin.
>
> It took me a couple of evenings to implement, and 90% of the time was
> spent trying to understand the Trac codebase so I was suprised when
> told
> it was too big (btw, "very high quality code" should be easy to read
> and
> understand - I think Trac still has some potential in that respect).
> Well,
> I wrote the plugin, but it was not a pleasant experience. It was much
> harder to write, uglier, required a plethora of hacks due to
> shortcomings
> in the plug-in API, but I managed. I figured I would wait until 0.11
> was
> released in case last minute changes affected my plugin. I've been
> waiting
> since December.
I would rather see the API fixes in Trac core than the original patch.
Subcomponents really are a feature I would rather see in a plugin, because
the vast majority of people don't need or want them.
> If I had gotten at least some feedback (even "your code sucks, clean it
> up"), you would have seen many more patches from me.
>
> Suggestions:
> - Live up to your mission statement. Do it the Bazaar way (see book for
> details)
> - Spend a bit less time on development and a bit more time at looking
> at
> other peoples patches that could be included. If you do, Trac will move
> forward at a much higher pace. Users will be encouraged and more people
> will join and write patches to include.
>
> Add functionality in baby steps. Some crappy support is better than
> zip,
> zilch, nothing. Users can give feedback (even in the form of patches)
> as
> you go along steering you towards a better product. Nobody (maybe
> except a
> handful in the world) are able to design and write the perfect system
> without a couple of iterations. Everything can be rewritten (with a
> proper
> testsystem, without fear), and database tables can be altered anyway
> you
> like during an upgrade.
Apparently you didn't read what I said. We specifically avoid this model. It
leads to poor design and even worse implementations.
> There is a reason why so many "other FOSS projects" work this way. It
> is
> more efficient. It is the Bazaar way.
It also leads to giant, messy piles of garbage. It shows when something has
been built with a single, coherent vision, and I think this is a large part
of why people like Trac in the first place.
--Noah
Endre Bakka
> Subcomponents really are a feature I would rather see in a plugin,
> because
> the vast majority of people don't need or want them.
I find it very very hard to believe that the vast majority don't need
subcomponents. And if some don't want them, they won't see them anyway. If
you don't add a subcomponent in the admin window, they don't have to be
showed elsewhere neither. Non-intrusive = all good. It's there for those
who need it, and not in the way for those who don't. When you need it and
it's not there and you have to hunt down a plugin from track-hacks,
install it and worry about maintenance, it get's in the way.
> Apparently you didn't read what I said. We specifically avoid this
> model. It
> leads to poor design and even worse implementations.
Yes I did read and understand you, I'm just arguing that you're wrong ;-).
So does a lot of brilliant developers (have you read that book btw?)
Also, you say you avoid this model. Tracs homepage states otherwise. Do
all core maintainers agree on this? In that case, changing the homepage is
in order. If not, I think this is the time to voice your opinion.
>> There is a reason why so many "other FOSS projects" work this way. It
>> is
>> more efficient. It is the Bazaar way.
>
> It also leads to giant, messy piles of garbage. It shows when something
> has
> been built with a single, coherent vision, and I think this is a large
> part
> of why people like Trac in the first place.
I would not call the linux kernel, git and firefox for giant messy piles
of garbages. But I have a feeling we disagree on many things.
I liked Trac because your homepage said you followed the Bazaar
methodology. Most users judge by features, stability and release cycles.
- Endre
Endre Bakka
>> really
>> don't understand where people get this idea. Trac is already just a
>
> talked about trac-hacks++ and a nice plugin installer. That would go a
> long way to dispel the notion that "trac-hacks" are bad. I also think
Two reasons:
- Trust
- Maintenance
Trust: If you install Trac in a company environment, downloading plugins
from "track-hacks.org" does not give you a good feeling. Moving the most
commonly used and actively maintained plugins to the main site would help
a lot. Adding a note that says "These plugins are mostly maintained by
Trac developers, but kept outside Trac because they are not considered to
be core functionality" would also help.
Maintenance: The number of orphaned plugins on track-hacks explains why we
worry about this. Will my plugin be maintained and work with the next
version, or will it just get me into a shitload of trouble?
- Endre
Noah Kantrowitz
> From: trac...@googlegroups.com [mailto:trac...@googlegroups.com] On
> Behalf Of Endre Bakka
> Sent: Thursday, June 19, 2008 3:18 PM
> To: trac...@googlegroups.com
> Subject: [Trac-dev] Re: Is Redmine a better Trac? What's gone wrong
> with Trac?
>
>
> patch.
> > Subcomponents really are a feature I would rather see in a plugin,
> > because
> > the vast majority of people don't need or want them.
>
> I find it very very hard to believe that the vast majority don't need
> subcomponents. And if some don't want them, they won't see them anyway.
> If
> you don't add a subcomponent in the admin window, they don't have to be
> showed elsewhere neither. Non-intrusive = all good. It's there for
> those
> who need it, and not in the way for those who don't. When you need it
> and
> it's not there and you have to hunt down a plugin from track-hacks,
> install it and worry about maintenance, it get's in the way.
Please read my blog post. Saying "plugins are hard to install" doesn't mean
things shouldn't be plugins, it means we should make installing plugins
easier. Fixing the right problem benefits everyone in the long run. As for
worrying about maintenance, most plugins update much faster and more
frequently than Trac itself, so I'm not sure what you think you will gain.
> > Apparently you didn't read what I said. We specifically avoid this
> > model. It
> > leads to poor design and even worse implementations.
>
> Yes I did read and understand you, I'm just arguing that you're wrong
> ;-).
> So does a lot of brilliant developers (have you read that book btw?)
Yes, on several occasions. I just disagree with parts of it for user-facing
software.
> Also, you say you avoid this model. Tracs homepage states otherwise. Do
> all core maintainers agree on this? In that case, changing the homepage
> is
> in order. If not, I think this is the time to voice your opinion.
Other developers have been fairly quiet on this thread, but I would never
presume to speak for them.
> >> There is a reason why so many "other FOSS projects" work this way.
> It
> >> is
> >> more efficient. It is the Bazaar way.
> >
> > It also leads to giant, messy piles of garbage. It shows when
> something
> > has
> > been built with a single, coherent vision, and I think this is a
> large
> > part
> > of why people like Trac in the first place.
>
> I would not call the linux kernel, git and firefox for giant messy
> piles
> of garbages. But I have a feeling we disagree on many things.
You clearly have never read the code for any of these. Go ahead, I'll wait.
Let me know when they figure out how to make gecko usefully modularized.
Last I saw they decided to give up for a while because it has so much global
state scattered everywhere. Git is a seemingly random assortment of C, shell
scripts, and perl. The developers actively opposed having a single API
(libgit) because they felt it would be limiting. The linux kernel has more
legacy crap in it than most software will ever see. When was the last time
you wanted to use a DECNET DNA network? So yes, this are all hugely
disorganized and poorly designed projects.
--Noah
Simon Martin
On Jun 19, 11:45 pm, "Noah Kantrowitz" <n...@coderanger.net> wrote:
[...]
> I would rather see the API fixes in Trac core than the original patch.
> Subcomponents really are a feature I would rather see in a plugin, because
> the vast majority of people don't need or want them.
various different features and I would really like to know what are
the reasons for this assumption.
Anyway, I'm just a user of Trac and haven't contributed anything to
Trac yet, but I followed many discussions the past year on Trac's
mailing-lists. I really don't understand why Trac isn't shipped with a
package of commonly used plugins (AccountManager, IniAdmin etc.). Or
maybe it would be enough to provide and maintain this package on t.e.o
to ensure that this package always works with the actual release.
Especially for AccountManager again I really don't understand, why
this is still a plugin. For nearly every login problem raised on trac-
users, the answer is "Install AccountManagerPlugin".
Why does a plugin provide this really basic functionality?
Just my 2 cents
Simon
Risto Kankkunen
> >> Unrelated to this is the idea that doing things in plugins is bad. I
> >> really don't understand where people get this idea.
> - Trust
> - Maintenance
problems come from "trust" (in the general sense, e.g the quality of
the code etc.), maintenance and other user experience problems (I
wrote recently about first not finding and then trying to figure out
which one of the 3 Wiki Include plugins to use).
I'm also wondering what is the additional cost for users to include
"extra functionality that not everyone uses"? I think the intersection
of functionality that everyone uses is about an empty set anyway...
Having much more functionality available right out of the box (but
still configurable of course) would be much more user friendly. I
wouldn't worry about increasing the package size or even the Trac
process size.
Including optional functionality in the "core" (as plugins or as core
features not using plugin APIs) would also have the same kind of
benefit that Linux has with their divers: when you make changes to
unstable APIs the core maintainers can pretty easily make fairly
mechanical search+replace through the code tree to update the plugins.
It would require much more for each individual plugin maintainer to do
the same.
I think Trac could also encourage experimentation by assigning some
APIs non-frozen or experimental and the others as frozen (Mozilla does
this, yes). Trac-hacks could be the place to experiment with plugins
using experimental APIs to see if they work in practice and can be
frozen in some future release.
I see Noah and Endre talk past each other, because Noah looks only at
the developer experience (Trac code is perfect and we keep releasing
only perfect code, plugins don't have technical problems) and Endre
thinks about the user experience (Trac is highly imperfect for almost
every use case since it contains only the common subset of features
everyone needs and that is close to the empty set, figuring out what
plugins to use is a pain). There are no technical solutions to address
Endre's comments, it's about the mindset and attitude. If Trac is not
just a programming exercise, it needs to pay attention to the user
experience as well.
I know Linux and Firefox (and git) are not perfect, but I thank their
developers for not trying to make them perfect and force me to use
some other non-perfect OS and browser. It's also a fallacy that people
would switch using the perfect Trac (or OS or browser) once it is
released in the distant future; good enough is good enough for users.
The perfectness of the code is not a value in itself, it's only a
means to make a better product faster. Having a rapidly improving
product also attracts more developers which helps to improve the
product faster and making less short-cuts while doing so.
andre...@gmail.com
(AccountManager, AutoQueryPlugin, IniAdmin etc.).
By the way, what is the evaluation process used (or that should be
used) to decide if a feature/plugin/whatever should be included into
Trac or shipped with Trac?
André
On Jun 20, 10:17 am, Risto Kankkunen <risto.kankku...@gmail.com>
wrote:
Alec Thomas
Excellent post Risto.
I'm not sure what the solution is, but it's obvious that the status
quo could stand to be improved.
--
Evolution: Taking care of those too stupid to take care of themselves.
Alec Thomas
>
> I vote for Trac being shipped with a package of commonly used plugins
> (AccountManager, AutoQueryPlugin, IniAdmin etc.).
AutoQueryPlugin is a perfect example of the effort surrounding
including plugins in Trac. I'm not bashing the author, but the major
blocker is mentioned on the plugins page: "This plugin overrides the
ticket.html template to do this. Ideally, this wouldn't have to be
done, but it was the easiest solution to the problem."
This plugin couldn't be shipped with Trac with that approach.
TBH, this would be better implemented as a patch against trunk. If one
were provided it would likely be included.
>
> By the way, what is the evaluation process used (or that should be
> used) to decide if a feature/plugin/whatever should be included into
> Trac or shipped with Trac?
Historically, the WebAdmin and Spam plugins are the only two imported
into Trac. Both started life as plugins hosted on t.e.o, both were
written by cmlenz, and both were imported by him. Both were also long
overdue.
However, so are others in my opinion: AccountManager definitely.
Trac developers, I think we should take a vote on the following:
I propose we move high (or even medium) quality, popular plugins
onto t.e.o. Perhaps into the sandbox or a new "plugins" path
initially. Then ship them with Trac, configured but disabled. If the
plugins stagnate, we remove them, or we pick up maintenance. We change
our model to rely on plugin authors to maintain quality plugins within
Trac, rather than treating them as second-class citizens of the
community.
We have ideas for making plugin integration even smoother, such as
automatic installs from t-h, a plugin "configuration" web interface,
but these are quite a way away and people need these features. Why are
we persisting in making life difficult for our users?
(For general information, each plugin on
http://staging.trac-hacks.org/hacks is weighted by the number of hits
from the trac-hacks apache logs. It's a fair metric of popularity, but
not necessarily quality. XmlRpcPlugin (which I wrote), for example, is
really horrible code. I'd be disturbed if it were included with Trac.)
Anyway, it's late and this is probably incoherent, so I'm going to bed :)
--
Jeff Hammel
>
> >> Unrelated to this is the idea that doing things in plugins is bad. I
> >> really
> >> don't understand where people get this idea. Trac is already just a
> >
> > It would be good to get feedback about why ppl feel this way. Noah has
> > talked about trac-hacks++ and a nice plugin installer. That would go a
> > long way to dispel the notion that "trac-hacks" are bad. I also think
>
> Two reasons:
> - Trust
> - Maintenance
>
> Trust: If you install Trac in a company environment, downloading plugins
> from "track-hacks.org" does not give you a good feeling. Moving the most
> commonly used and actively maintained plugins to the main site would help
> a lot. Adding a note that says "These plugins are mostly maintained by
> Trac developers, but kept outside Trac because they are not considered to
> be core functionality" would also help.
I agree there is much that could be done as far as branding of trac and trac-hacks. As a developer and my organization's "trac guy", this doesn't really concern me as I have taken the time to investigate plugins and see what works for our needs.
Why trust any software found on the internet? Generally, people do so because the site isn't irreputable and the software (at least from the description) seems to fit their needs. An open-source bug tracker is not going to have the same perceived guarantee of commercial software, and will take more expertise to install and configure. I agree much could be done to make the perception better and improve documentation especially regarding general use case and "how to make trac do what you want" (user stories).
Putting all plugin functionality in core and bundling it together would not improve my trust of the code; it would decrease it, as it would make trac more of a monolith, regardless of whether all the switches to turn things on or off would be shown (and if they were all shown, I would guess the plethora of configuration options would overwhelm new users). I can see how doing this would increase the perception of the "unified nature" of the code to some people, particularly those that just wanted to throw up a bug tracking system without really figuring out how it works. But I think much more could be gained by making installation more straight-forward (front-ending it, that is) and adding documentation and bettering the sites' branding.
> Maintenance: The number of orphaned plugins on track-hacks explains why we
> worry about this. Will my plugin be maintained and work with the next
> version, or will it just get me into a shitload of trouble?
This is a general issue of all software, and I don't think applies particularly to trac or component architectures. I think the process in trac is more straight-forward than for many OSS projects. If a plugin is not maintained, I'm sure most authors would be glad to let outsiders take over their projects. Even ignoring this, the wiki is edittable and patches can be posted, and at worse, plugins can be forked. I think the trouble is finding developers who will step up to the plate to do the maintainence work. Shifting more plugins to be part of trac core doesn't ease maintainence, it just shifts the workload to the core developers. Some plugins (or parts of some plugins) are slated for core, but I think by allowing and encouraging third party plugins trac not only gets more community participation but also free development on matters that users really care about.
None of this is an answer to the IT manager that wants a bug tracker to work out of the box yesterday. I'm not ignoring that concern, which I think is valid, but it isn't one of my concerns. I don't know if trac is currently at a state where it fits that use-case. As someone who is content to tweak and do detailed setup, I'd rather see more core development effort go to the guts of the code than to making things easily integratable for those that want an out of the box solution.
Jeff Hammel
The Open Planning Project
http://topp.openplans.org
Mike
>
> Subcomponents really are a feature I would rather see in a plugin, because
> the vast majority of people don't need or want them.
>
valid and
most of the times is baseless i.e. without any data supporting it.
May be it is a good idea to poll people on what functionality they
need or want.
The PollMacro from the trac-hacks on the t.e.o would do a big help in
discussing
what is needed and what is not.
Regards,
Mikhail
Jeff Hammel
>
> 2008/6/20 andre...@gmail.com <andre...@gmail.com>:
> >
> > I vote for Trac being shipped with a package of commonly used plugins
> > (AccountManager, AutoQueryPlugin, IniAdmin etc.).
>
> AutoQueryPlugin is a perfect example of the effort surrounding
> including plugins in Trac. I'm not bashing the author, but the major
> blocker is mentioned on the plugins page: "This plugin overrides the
> ticket.html template to do this. Ideally, this wouldn't have to be
> done, but it was the easiest solution to the problem."
>
> This plugin couldn't be shipped with Trac with that approach.
>
> TBH, this would be better implemented as a patch against trunk. If one
> were provided it would likely be included.
Now that I know that such a patch would be welcome and likely to be included, I'll work on it after returning from vacation:
http://trac-hacks.org/ticket/3226
jeff
Erik Bray
>
>> I would rather see the API fixes in Trac core than the original patch.
>> Subcomponents really are a feature I would rather see in a plugin,
>> because
>> the vast majority of people don't need or want them.
>
> I find it very very hard to believe that the vast majority don't need
> subcomponents. And if some don't want them, they won't see them anyway. If
> you don't add a subcomponent in the admin window, they don't have to be
> showed elsewhere neither. Non-intrusive = all good. It's there for those
> who need it, and not in the way for those who don't. When you need it and
> it's not there and you have to hunt down a plugin from track-hacks,
> install it and worry about maintenance, it get's in the way.
Just to throw in my $0.02 USD on this (what I see as relatively minor)
issue. Perhaps you're right that allowing some form of subcomponents
can't *hurt*. But I will wave my hand as someone who doesn't need or
want them. I have a hard enough time getting people to select the
correct component for tickets as it is. No need for subcomponents.
Adding a \ is generally good enough for adding a second level. A
third level starts to get ridiculous. And I'm not to thrilled about
existing implementations I've seen of this anyways. I'd much rather
see the API extended to better support the implementation of such a
thing. I'm usually happy to see more extension points, because then I
can do what *I* need to do with them, and not what someone else
thought was a good idea.
Erik
Erik Bray
> Historically, the WebAdmin and Spam plugins are the only two imported
> into Trac. Both started life as plugins hosted on t.e.o, both were
> written by cmlenz, and both were imported by him. Both were also long
> overdue.
>
> However, so are others in my opinion: AccountManager definitely.
>
Definitely agreed on large chunks of AccountManager. Most people
don't really seem to be familiar with how the HTTP authentication
methods work. They just to be able to register users through the web
and log in via an HTML form, like they're used to from most other CMSs
out there. This seems to be the most common use case, and making it
more easily available, I think, would eliminate an enormous chunk of
the support questions on the mailing list. Those of us who need to
switch to different user management backends, or integrate with
existing web server authentication, are more likely to know what we're
doing anyways. Or at the very least, being less common use cases I
think there would be fewer questions about alternative authentication
setups. I have no data on this of course, but a browse through the
mailing list archives seems to suggest that most people don't need or
want to think very hard about authentication.
Erik
rupert....@gmail.com
difference to so many other wikis.
On Jun 20, 5:36 pm, "Erik Bray" <hyugaricd...@gmail.com> wrote:
Noah Kantrowitz
> From: trac...@googlegroups.com [mailto:trac...@googlegroups.com] On
> Behalf Of Alec Thomas
> Sent: Friday, June 20, 2008 7:18 AM
> To: trac...@googlegroups.com
> Subject: [Trac-dev] Re: Is Redmine a better Trac? What's gone wrong
> with Trac?
>
>
-1. You are trying to solve a PR problem with a technical solution. There
will always be that one plugin that someone wants, that we don't include.
Unless you propose to basically merge t.e.o and trac-hacks (possibly not a
bad idea eventually, but not a discussion for today), this won't do much
IMO. You know and I know what plugins on trac-hacks are up to snuff, and we
are quite clear about it in many places (see how many guides recommend
installing AccountManager). I would propose an alternate solution, the
creation of a "new" project that is officially recognized by t.e.o in some
way as being the turnkey solution so many people want. Perhaps something
like bitnami+oforge+some common options and config settings. "Trac" remains
the minimalist system we all know and love, and anyone installing it will
continue to get the same experience. People wanting the turnkey version can
get $NEWPROJECT, and not care about what particular components it pulls in.
--Noah
Erik Bray
> I would propose an alternate solution, the
> creation of a "new" project that is officially recognized by t.e.o in some
> way as being the turnkey solution so many people want. Perhaps something
> like bitnami+oforge+some common options and config settings. "Trac" remains
> the minimalist system we all know and love, and anyone installing it will
> continue to get the same experience. People wanting the turnkey version can
> get $NEWPROJECT, and not care about what particular components it pulls in.
>
That's a really great idea, actually. An official Trac turnkey
solution, Trac+ or something, with some of the features and plugins
that people want most provided by default, and maintained alongside
the basic Trac. Maybe such a thing could stave off any fork efforts.
It could even use the same code base, and just be deployed via a
different setup.py argument or something. I'm not sure if that's
exactly what you had in mind, but it would make for a relatively
painless solution for now...
Erik
John Hampton
<snip>
> -1. You are trying to solve a PR problem with a technical solution. There
> will always be that one plugin that someone wants, that we don't include.
> Unless you propose to basically merge t.e.o and trac-hacks (possibly not a
> bad idea eventually, but not a discussion for today), this won't do much
> IMO. You know and I know what plugins on trac-hacks are up to snuff, and we
> are quite clear about it in many places (see how many guides recommend
> installing AccountManager). I would propose an alternate solution, the
> creation of a "new" project that is officially recognized by t.e.o in some
> way as being the turnkey solution so many people want. Perhaps something
> like bitnami+oforge+some common options and config settings. "Trac" remains
> the minimalist system we all know and love, and anyone installing it will
> continue to get the same experience. People wanting the turnkey version can
> get $NEWPROJECT, and not care about what particular components it pulls in.
Actually, I think Alec was trying to solve a PR problem with a
completely PR solution. Moving "popular" plugins to t.e.o doesn't
change the quality or function of the code, it simply gives it a more
"positive" spin (isn't that what PR's all about?). Including some
plugins in the tarball of the trac distribution saves all of 4 or 5
commands, and in no way changes the effectiveness of the code, but it
does make people feel like they are getting "more".
Now, I am actually -1 for moving "popular" plugins onto t.e.o because I
don't think it's worth it. Same with bundling popular plugins in the
tarball.
However, I do think that we need to make it much clearer on both t.e.o
and t-h.o that t-h.o IS the OFFICIAL place for trac plugins. If we
don't like the "hacks" part of t-h.o, then let's look into getting
another name to make the official plugin repos.[2]
The other things we can do on t-h.o are:
1) Don't show all plugins by default, only show those that have been
"vetted" (migrating to 0.11 and the VotePlugin would help here)
2) Create a section for plugins maintained by the core devs
3) (Optional) Create a "recommended by" section for the core devs to
put the plugins that they use and recommend
I'm also all for community projects like oforge, but more on that in the
following thread:
http://groups.google.com/group/trac-dev/browse_thread/thread/23f12595cff16914
-John
Noah Kantrowitz
> -----Original Message-----
> From: trac...@googlegroups.com [mailto:trac...@googlegroups.com] On
> Behalf Of John Hampton
> Sent: Friday, June 20, 2008 1:03 PM
> To: trac...@googlegroups.com
> Subject: [Trac-dev] Re: Is Redmine a better Trac? What's gone wrong
> with Trac?
>
> >
> However, I do think that we need to make it much clearer on both t.e.o
> and t-h.o that t-h.o IS the OFFICIAL place for trac plugins. If we
> don't like the "hacks" part of t-h.o, then let's look into getting
> another name to make the official plugin repos.[2]
My working title for the new index has been TracPI (in honor of PyPI), do
people like that better?
>
> The other things we can do on t-h.o are:
> 1) Don't show all plugins by default, only show those that have been
> "vetted" (migrating to 0.11 and the VotePlugin would help here)
> 2) Create a section for plugins maintained by the core devs
> 3) (Optional) Create a "recommended by" section for the core devs to
> put the plugins that they use and recommend
Perhaps do a "Featured plugin" section once a week or something. Alec or I
(or any other trusted community member) could do a short writeup on a
popular plugin, possibly along with screenshots, sample configs, pointers to
sites using it, etc. I would then include a link to that page in the default
WikiStart, just in the hopes that people will see it.
--Noah