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
John Hampton
> My working title for the new index has been TracPI (in honor of PyPI), do
> people like that better?
I don't mind the trac-hacks name, however, if other think that switching
is desired, then I think TracPI is just fine.
> 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.
I think that's a good idea. Once a week might be a bit much, but then
again, maybe not. However, I agree that having some write-ups regarding
usage, installation, etc. by community members is a good thing.
-John
Alec Thomas
>> 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.
>
> -1. You are trying to solve a PR problem with a technical solution. There
No not really. It's about 1/3 technical, 1/3 PR and 1/3 community.
The technical aspect it that I envisaged the plugins not requiring any
trac-admin upgrade, or real configuration. They have a basic working
out-of-the-box config and all they would need is to be enabled in
webadmin.
The PR aspect is that users get more functionality out of the box. This
is a good thing.
The (developer) community aspect is that Trac core hopefully gets more
developers involved in working on the core rather than just sticking to
plugins.
> 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.
I think this is a good idea. +1
TBH, I'm not really convinced my proposal is the right solution, I'm
more hoping that if everybody throws out some ideas we'll come up with
a solution.
rupert....@gmail.com
lead to quick implementation of "big user base features" like ajax
selecting author, cc, ... see: http://www.redmine.org/issues/show/1308.
On Jun 19, 1:35 am, "andref.d...@gmail.com" <andref.d...@gmail.com>
wrote:
> 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?
>
> Regards,
>
> André
rupert....@gmail.com
> My working title for the new index has been TracPI (in honor of PyPI), do
> people like that better?
trac?
rupert.
Noah Kantrowitz
I have been trying quite hard to avoid forking the package index, but
I have been unable to get a response from the catalog-sig about any of
my patches. PyPI/distutils makes a number of assumptions about
packaging that don't really apply to Trac plugins, the biggest example
being that uploading a new version will hide all prior version. When
dealing with multiple maintenance branches, this is generally
unhelpful. Also the XML-RPC search API is woefully inadequate.
--Noah
Eli
[snip]
> 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.
I don't think we should start $NEWPROJECT. Trac has a lot of name
recognition... and we need to keep that.
Just for the record, the plugins I use on most every Trac I setup:
AccountManager and Graphviz. The latter I don't see as an item for 'core',
but graphviz is an awesome tool. :)
Other comments regarding this thread; primary audience is the other devs:
I think that AccountManager needs to migrate to Trac core just as WebAdmin
did. And I think the form-based login needs to be the default. Since 0.12
is "translation & internationalization", I don't think we should include it
in our next release... but I think we need to get 0.12 out ASAP. Then add
AccountManager to core, and call it 0.13, and again, get that release out
ASAP. We need to improve our "momentum" (for lack of a better term).
I think we (the developers) need to take this discussion as something of
a 'wake-up call'. I don't think we should go into a panic, but I think we
need to go back and challenge some of the things we "know" about our users'
needs. Our user base has been growing... but I think it has been growing in
different proportions to what it started as, so our user base as a whole is
probably very different than it was.
But if I tried to specify how the user base has changed, or what the most
pressing needs are, I would just be guessing.
We need real data here. And I think we have some to look at -- trac-hacks and
t.e.o.
For trac-hacks, we need to figure out what the most downloaded plugins are...
that will give us insight into our users' needs. Then, we need to start at
the top, and for each plugin answer these questions (and do it publicly, on a
t.e.o wiki page, dev-editable only):
* How well does the plugin live up to its goal?
If it doesn't do what it claims, or does it poorly, this is a portion of our
userbase that is either unhappy, or went to something else since it wasn't
good enough. (I'm guessing that one of these will be the Gantt plugin.)
* What ugliness in the plugin could be removed by adding an extension point
(or whatever) to Trac?
If we have a popular plugin that has to use ugly tricks to do what it needs,
we need to fix Trac to support it well... and prioritize that fix based on
the plugin's popularity.
* What is the quality of the plugin's code?
If the code is horrible, but it is popular, we need to get the code improved.
We'll probably want to try: track down the maintainer, see if others can help
out, try to energize the community for that plugin so it improves.
For t.e.o, we need to find the most "popular" tickets. What are people
clamoring for in our buglist? Can we find someone to champion those?
Other things we need to look at are:
* For each extension point in Trac, is there a plugin that uses it? If not,
can we articulate the reason for that extension point, or should we maybe
remove it? (Should be openly trumpetted on the mailing lists if we think the
latter.)
* What are the most common search terms on t.e.o? Are people finding what
they need, or are they just getting frustrated?
* Same as the above, but for t-h.
* It may also be enlightening to find out what the most common Google searches
that include "trac" are, if there is a way to find that out. It may also
tell us something surprising.
* Trac code quality. While increasing the testing line coverage, I found a
number of bugs, and in general, found my opinion of our codebase decline.
(And let me state for the record: much of it was looking at code I had a hand
in.)
Wow. Essay. And yikes, there's a lot of work to be done here.
Hm. I have an idea, and I'm going to try to lead by example on this....
separate email to follow.
Thoughts?
Eli
------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
retr...@gmail.com `-------------------------------------------------
Noah Kantrowitz
There had been some talk on IRC about doing a voluntary usage
statistics as part of the install and upgrade processes. Data like
installed plugins, number of users, size of wiki and ticket database,
version control system in use, etc etc. We all kind of dislike the
idea, as they usually turn into PR nightmares. What do all you non-
Trac-developers think about this?
--Noah
Alec Thomas
>
> On Friday 20 June 2008 01:04:03 pm Noah Kantrowitz wrote:
> [snip]
>> 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.
>
> I don't think we should start $NEWPROJECT. Trac has a lot of name
> recognition... and we need to keep that.
>
> Just for the record, the plugins I use on most every Trac I setup:
> AccountManager and Graphviz. The latter I don't see as an item for 'core',
> but graphviz is an awesome tool. :)
>
>
> Other comments regarding this thread; primary audience is the other devs:
>
> I think that AccountManager needs to migrate to Trac core just as WebAdmin
> did. And I think the form-based login needs to be the default. Since 0.12
> is "translation & internationalization", I don't think we should include it
> in our next release... but I think we need to get 0.12 out ASAP. Then add
> AccountManager to core, and call it 0.13, and again, get that release out
> ASAP. We need to improve our "momentum" (for lack of a better term).
+1 on everything here. One of the most frequent complaints is about the
auth system relying on <your-webserver-here>.
> I think we (the developers) need to take this discussion as something of
> a 'wake-up call'. I don't think we should go into a panic, but I think we
> need to go back and challenge some of the things we "know" about our users'
> needs. Our user base has been growing... but I think it has been growing in
> different proportions to what it started as, so our user base as a whole is
> probably very different than it was.
Agreed again.
> For t.e.o, we need to find the most "popular" tickets. What are people
> clamoring for in our buglist? Can we find someone to champion those?
This is a good idea, and perhaps the CC count could be used as a
reasonable marker.
> Other things we need to look at are:
> * For each extension point in Trac, is there a plugin that uses it? If not,
> can we articulate the reason for that extension point, or should we maybe
> remove it? (Should be openly trumpetted on the mailing lists if we think the
> latter.)
> * What are the most common search terms on t.e.o? Are people finding what
> they need, or are they just getting frustrated?
> * Same as the above, but for t-h.
> * It may also be enlightening to find out what the most common Google searches
> that include "trac" are, if there is a way to find that out. It may also
> tell us something surprising.
> * Trac code quality. While increasing the testing line coverage, I found a
> number of bugs, and in general, found my opinion of our codebase decline.
> (And let me state for the record: much of it was looking at code I had a hand
> in.)
I've created two Wiki pages:
http://trac.edgewall.org/wiki/SeaChange
For high level observations about problems with Trac's development
and http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant
For collecting random thoughts users have about what they want.
Hopefully we can distil something useful from these pages.
Please contribute! If we can identify what the most pressing problems
are, we can work toward fixing them.
Remy Blank
> statistics as part of the install and upgrade processes. Data like
> installed plugins, number of users, size of wiki and ticket database,
> version control system in use, etc etc. We all kind of dislike the
> idea, as they usually turn into PR nightmares. What do all you non-
> Trac-developers think about this?
I use Trac at home and at work, and I would be willing to provide such
data for both instances. That's not much data, but I guess every little
bit helps.
-- Remy
Alec Thomas
> I've created two Wiki pages:
>
> http://trac.edgewall.org/wiki/SeaChange
> For high level observations about problems with Trac's development
>
> and http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant
> For collecting random thoughts users have about what they want.
> Hopefully we can distil something useful from these pages.
>
> Please contribute! If we can identify what the most pressing problems
> are, we can work toward fixing them.
Christian has made a very useful report on the popular tickets:
http://trac.edgewall.org/report/32
Jani Tiainen
> 2008/6/22 Alec Thomas <al...@swapoff.org>:
>> I've created two Wiki pages:
>>
>> http://trac.edgewall.org/wiki/SeaChange
>> For high level observations about problems with Trac's development
>>
>> and http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant
>> For collecting random thoughts users have about what they want.
>> Hopefully we can distil something useful from these pages.
>>
>> Please contribute! If we can identify what the most pressing problems
>> are, we can work toward fixing them.
>
> Christian has made a very useful report on the popular tickets:
>
> http://trac.edgewall.org/report/32
Nice report altough I don't really get how all those features have
gotten so long CC lists.. :D
Some of those tickets are more like in-place functionality, which
reminds me about that generalization + JSON support (that is supposed to
be in XMLRPC plugin that I upgraded few weeks ago to match some changes).
Maybe this would be good time to test it properly since it would expose
more ways to interact from javascript, specially jquery loves json...
--
Jani Tiainen
Jani Tiainen
> 2008/6/22 Alec Thomas <al...@swapoff.org>:
>> I've created two Wiki pages:
>>
>> http://trac.edgewall.org/wiki/SeaChange
>> For high level observations about problems with Trac's development
>>
>> and http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant
>> For collecting random thoughts users have about what they want.
>> Hopefully we can distil something useful from these pages.
>>
>> Please contribute! If we can identify what the most pressing problems
>> are, we can work toward fixing them.
>
> Christian has made a very useful report on the popular tickets:
>
> http://trac.edgewall.org/report/32
And since topic is about redmine, how about we steal a bit from it's
ticketing system.
I really liked their custom field system: basically you could have 3
types of fields: simple text (singleline), long text (multiline) and
list of enumerations.
What was best was that you could enter regular expression for field
validation. Of course it eats a bit more space from database but you
could enter for example dates and keep them valid. Of course regex is a
bit complex but for most things there already exists nice recipes.
So what if Trac core could provide set of primitive fields, basically
numbers, dates, texts and enumerated lists (including internal lists
like milestones). That could resolve how to expand ticketing system for
many needs without doing massive changes to core, or have external
plugins to do so.
--
Jani Tiainen
Zoom.Quiet
<andre...@gmail.com> wrote:
>
> 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'm Chnese, i push my team usage Trac 4 years;
i like and understand and love Trac's philosophy :
pythonic,lightter,quickly ..
we hacking and hacking so many code for support norm. com. PM need...
http://trac-hacks.org/wiki/TracChineseTranslation
but like that base tools for PM:
workflow/philosophy/gannt report/...
Trac always not support...
why?!
Redmine support in start... is very bronk my mind...
python is better than Ruby,
but why the 1st agile PM env. -- Trac is can not hold the best postion?
http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''
> Regards,
>
> André
>
>
> >
>
Simon Martin
On Jun 22, 11:40 am, Remy Blank <remy.bl...@pobox.com> wrote:
> I use Trac at home and at work, and I would be willing to provide such
> data for both instances. That's not much data, but I guess every little
> bit helps.
Simon
Alec Thomas
>
> Alec Thomas kirjoitti:
>> 2008/6/22 Alec Thomas <al...@swapoff.org>:
>>> I've created two Wiki pages:
>>>
>>> http://trac.edgewall.org/wiki/SeaChange
>>> For high level observations about problems with Trac's development
>>>
>>> and http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant
>>> For collecting random thoughts users have about what they want.
>>> Hopefully we can distil something useful from these pages.
>>>
>>> Please contribute! If we can identify what the most pressing problems
>>> are, we can work toward fixing them.
>>
>> Christian has made a very useful report on the popular tickets:
>>
>> http://trac.edgewall.org/report/32
>
> Nice report altough I don't really get how all those features have
> gotten so long CC lists.. :D
>
> Some of those tickets are more like in-place functionality, which
> reminds me about that generalization + JSON support (that is supposed to
> be in XMLRPC plugin that I upgraded few weeks ago to match some changes).
What do you mean by "in-place functionality"?
And what do you mean by "generalization + JSON support"? Do you mean
seeing general-purpose JSON support in Trac core?
>
> Maybe this would be good time to test it properly since it would expose
> more ways to interact from javascript, specially jquery loves json...
--
Jani Tiainen
> 2008/6/23 Jani Tiainen <red...@gmail.com>:
>> Alec Thomas kirjoitti:
>>> 2008/6/22 Alec Thomas <al...@swapoff.org>:
>>>> I've created two Wiki pages:
>>>>
>>>> http://trac.edgewall.org/wiki/SeaChange
>>>> For high level observations about problems with Trac's development
>>>>
>>>> and http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant
>>>> For collecting random thoughts users have about what they want.
>>>> Hopefully we can distil something useful from these pages.
>>>>
>>>> Please contribute! If we can identify what the most pressing problems
>>>> are, we can work toward fixing them.
>>> Christian has made a very useful report on the popular tickets:
>>>
>>> http://trac.edgewall.org/report/32
>> Nice report altough I don't really get how all those features have
>> gotten so long CC lists.. :D
>>
>> Some of those tickets are more like in-place functionality, which
>> reminds me about that generalization + JSON support (that is supposed to
>> be in XMLRPC plugin that I upgraded few weeks ago to match some changes).
Shouldn't write anything without having that first cup of coffee in the
morning... :D
> What do you mean by "in-place functionality"?
From UI point of view - there seems to be at least few of tickets
asking doing (partial) changes just in-place, like editing ticket
comments or wiki section and posting them back to server.
> And what do you mean by "generalization + JSON support"? Do you mean
> seeing general-purpose JSON support in Trac core?
If you recall, I made that generalization of RPC backend and added JSON
(which follows pretty much XMLRPC) calls too. It was somewhere at the
beginning of this year. And no, not in core but in this fine plugin.
It could allow usage of SOAP too (if there will be reasonable SOAP
library for Python)
--
Jani Tiainen
Erik Bray
> Sayeahoo!
> i'm Chnese, i push my team usage Trac 4 years;
> i like and understand and love Trac's philosophy :
> pythonic,lightter,quickly ..
> we hacking and hacking so many code for support norm. com. PM need...
> http://trac-hacks.org/wiki/TracChineseTranslation
>
> but like that base tools for PM:
> workflow/philosophy/gannt report/...
>
> Trac always not support...
> why?!
> Redmine support in start... is very bronk my mind...
So because Trac doesn't support your particular development
process/philosophy it's broken? I think this attitude may be the
problem with much of the user community. They expect Trac to work
exactly for their development process, and if it doesn't it's
"broken". Yet they don't realize that the whole point of Trac is to
try to stay out of the way as much as possible and don't force much in
the way of a process, while the needs of specific processes can be
supported through the powerful plugin API.
Erik
Erik Bray
>> And what do you mean by "generalization + JSON support"? Do you mean
>> seeing general-purpose JSON support in Trac core?
>
> If you recall, I made that generalization of RPC backend and added JSON
> (which follows pretty much XMLRPC) calls too. It was somewhere at the
> beginning of this year. And no, not in core but in this fine plugin.
>
> It could allow usage of SOAP too (if there will be reasonable SOAP
> library for Python)
>
Not at all a terrible idea, though I'm not entirely sure why it's
necessary to include in the core. I have a small plugin (really just
an IRequestFilter) that includes the JSON extension for jQuery, and am
moving towards using JSON in all my plugins, where applicable. cjson
for the Python side. Still, not sure why this would be necessary for
inclusion in the Trac core unless JSON were to be used by Trac as
well.
Erik
Noah Kantrowitz
As we are looking to add more AJAXy features to Trac core (like the
ticketninja branch), having native JSON-RPC would be incredibly useful.
--Noah
Scott Bussinger
> http://trac.edgewall.org/report/32
think would require two things:
1) Explicitly stating that development on the project is going to be
at least partially guided by the number of people who "vote" for a
feature request by entering themselves in the CC field.
2) A definite show of support from the active developers on the
project to actually implement some of the popular features requested
(either in the core or as a supported plugin).
Tallying the CC field now is helpful but not particularly accurate. In
my own case for instance, I've put myself on the CC list for a couple
of tickets that I no longer care about and haven't put myself on the
CC list for some features I'd really love to have. If I thought it
actually mattered, I'd be far more likely to pay attention to what I'm
CC'd on. A standard report/query that displayed your own CC'd tickets
would help us to do that.
But I'm not going to waste my time with all that if I don't think it's
going to affect what gets worked on. Look at that report -- the top
several items are all 4 years old. While I love Trac and I really
appreciate all that the development team has done and is doing, the
Trac project does not have a reputation in the community at large for
being fast and responsive to requests.
Alec Thomas
>
>> Christian has made a very useful report on the popular tickets:
>> http://trac.edgewall.org/report/32
>
> This _is_ an interesting report. To make it truly useful though I
> think would require two things:
>
> 1) Explicitly stating that development on the project is going to be
> at least partially guided by the number of people who "vote" for a
> feature request by entering themselves in the CC field.
>
> 2) A definite show of support from the active developers on the
> project to actually implement some of the popular features requested
> (either in the core or as a supported plugin).
I agree 100%. I think we need to shift to a model of actively trying to
implement features users want. Workflow is a good example of this, but
we need to continue.
> Tallying the CC field now is helpful but not particularly accurate. In
> my own case for instance, I've put myself on the CC list for a couple
> of tickets that I no longer care about and haven't put myself on the
> CC list for some features I'd really love to have. If I thought it
> actually mattered, I'd be far more likely to pay attention to what I'm
> CC'd on. A standard report/query that displayed your own CC'd tickets
> would help us to do that.
>
> But I'm not going to waste my time with all that if I don't think it's
> going to affect what gets worked on. Look at that report -- the top
> several items are all 4 years old. While I love Trac and I really
> appreciate all that the development team has done and is doing, the
> Trac project does not have a reputation in the community at large for
> being fast and responsive to requests.
Yes, and it's a reputation we should strive to reverse.
--
And the next thing you know, you're at the zoo, shaving a yak, all so
you can wax your car.
Noah Kantrowitz
On Jun 23, 2008, at 1:13 PM, Alec Thomas wrote:
>
> 2008/6/24 Scott Bussinger <sco...@opto-pps.com>:
>>
>>> Christian has made a very useful report on the popular tickets:
>>> http://trac.edgewall.org/report/32
>>
>> This _is_ an interesting report. To make it truly useful though I
>> think would require two things:
>>
>> 1) Explicitly stating that development on the project is going to be
>> at least partially guided by the number of people who "vote" for a
>> feature request by entering themselves in the CC field.
>>
>> 2) A definite show of support from the active developers on the
>> project to actually implement some of the popular features requested
>> (either in the core or as a supported plugin).
>
> I agree 100%. I think we need to shift to a model of actively trying
> to
> implement features users want. Workflow is a good example of this, but
> we need to continue.
Can we install VotePlugin on t.e.o? I have a report to do summaries
using that instead and it might be clearer to people that those
numbers matter.
SELECT p.value AS __color__,
id AS ticket, sum(v.vote) as votes, summary, component, version,
milestone, t.type AS type,
owner, status,
time AS created,
changetime AS _changetime, description AS _description,
reporter AS _reporter
FROM ticket t, enum p, votes v
WHERE status <> 'closed'
AND p.name = t.priority AND p.type = 'priority'
AND v.resource = 'ticket/' || id
GROUP BY id, summary, component, version, milestone, t.type, owner,
time,
changetime, description, reporter, p.value, status
ORDER BY votes DESC, milestone, t.type, time
--Noah
Jonas Borgström
>
>
> On Jun 23, 2008, at 1:13 PM, Alec Thomas wrote:
>
>>
>> 2008/6/24 Scott Bussinger <sco...@opto-pps.com>:
>>>
>>>> Christian has made a very useful report on the popular tickets:
>>>> http://trac.edgewall.org/report/32
>>>
>>> This _is_ an interesting report. To make it truly useful though I
>>> think would require two things:
>>>
>>> 1) Explicitly stating that development on the project is going to be
>>> at least partially guided by the number of people who "vote" for a
>>> feature request by entering themselves in the CC field.
>>>
>>>
>>> 2) A definite show of support from the active developers on the
>>> project to actually implement some of the popular features requested
>>> (either in the core or as a supported plugin).
>>
>> I agree 100%. I think we need to shift to a model of actively trying
>> to
>> implement features users want. Workflow is a good example of this, but
>> we need to continue.
Ok, so you're saying that we currently focusing on unwanted features? ;)
Seriously though. "Voting" and other forms of feature popularity
indicators are good tools that we probably should use more.
But we also need to remember that even if somehow half the internet
voted on a particular feature doesn't automatically mean it's a good
candidate to include in the next release or at all.
> Can we install VotePlugin on t.e.o? I have a report to do summaries
> using that instead and it might be clearer to people that those
> numbers matter.
Sure, why not it's a lot better than abusing the cc field. Is it
possible to configure it to give each user (or email) a limited number
of votes? I think you'll give your decisions a bit more thought if you
know you can only vote on 5-10 tickets at a time.
/ Jonas
Christian Boos
>> Christian has made a very useful report on the popular tickets:
>> http://trac.edgewall.org/report/32
>>
>
> This _is_ an interesting report. To make it truly useful though I
> think would require two things:
>
> 1) Explicitly stating that development on the project is going to be
> at least partially guided by the number of people who "vote" for a
> feature request by entering themselves in the CC field.
>
Well, using the CC count as a way to measure the popularity of a ticket
is only a kind of a hack... There are many biases to this approach. For
example, one thing that I have witnessed several times is that when
there's some renewed activity on a long-standing ticket where many
people are on CC, the next thing you will observe is that a lot of
people will *remove* themselves from the list. That can be interpreted
in many ways, but most probably those people have either found a
workaround within Trac, or a Trac replacement in the meantime. So while
the subscribing is indicative of interest, the unsubscribing could be
taken as a "dissatisfaction" indicator.
But nevertheless, that report gives an idea about what some users want
(or wanted) over time.
> 2) A definite show of support from the active developers on the
> project to actually implement some of the popular features requested
> (either in the core or as a supported plugin).
>
That does happen, I should make another report, similar to {32} but for
what has already been accomplished.
Here it is: http://trac.edgewall.org/report/33
Now the problem is to find those active developers ... the solution
being, become an active developer yourself!
> But I'm not going to waste my time with all that if I don't think it's
> going to affect what gets worked on. Look at that report -- the top
> several items are all 4 years old. While I love Trac and I really
> appreciate all that the development team has done and is doing, the
> Trac project does not have a reputation in the community at large for
> being fast and responsive to requests.
>
Well, lobbying is one thing, getting effectively involved is another,
and more effective in the long run. There are many ways to help the
project, Jani mentioned setting up a documentation team, Jeroen is
motivating people around the world to contribute translations, etc.
Before making the more ambitious changes that usually correspond to
long-standing issues, it is possible for anyone to start getting more
involved by tackling any problem of intermediate size, from trivial to
complex. The contribution can be anything, from testing a proposed fix
(there are /many/ problems nearly fixed, just awaiting feedback),
investigating strange configuration problems to shed some light on not
fully understood issues (e.g. #3663 of today), help to tweak the CSS or
the presentation of templates (e.g. #7075 of today), and so on.
Also, after the 0.11 release I've "reset the counters" on component
ownership, new tickets are no longer assigned to someone automatically (*).
That automatic assignment gave a false sense of confidence that the
ticket would actually be screened or managed by someone. We should
better face the reality that there are not really that many active core
developers around...
So starting from this reset we can either have new people engaging
themselves to monitor specific components of Trac, or leave the owner
unset and set the ownership in an ad-hoc way using the "assign to"
action. I'd even suggest that anyone (i.e. even when not formally part
of the TracTeam) could take ownership of a ticket, indicating by this
that he commits himself into resolving the ticket. I think that could
help stimulate newcomers to get more involved in the project.
We could even take this reset one step further by clearing that field
for all the existing opened tickets, not just the newer ones.
-- Christian
(*) usually that "someone" was me - but as said elsewhere, I have my own
idea of the "SeaChange" needed. Also, if any former component owner
thinks he should remain set as the owner, just put your name back, of
course.
Eirik Schwenke
Hash: SHA1
Christian Boos skrev 23-06-2008 20:31:
| Scott Bussinger wrote:
(...)
|> 2) A definite show of support from the active developers on the
|> project to actually implement some of the popular features requested
|> (either in the core or as a supported plugin).
|>
|
| That does happen, I should make another report, similar to {32} but for
| what has already been accomplished.
| Here it is: http://trac.edgewall.org/report/33
|
| Now the problem is to find those active developers ... the solution
| being, become an active developer yourself!
|
(...)
(...)
I like the idea of opening up development even more -- especially for bugfixes.
As Noha mentioned, design by chaos isn't a very good approach to software
engineering(**), but to allow all the monkeys (ie us trac users) to help hammer
out minor dents easily, is a good idea.
My limited experience so far has been that the trac team is responsive in this
regard, but I think lowering the bar a bit for developers to become part of the
core team (not by handing out svn commit access, but by making it even easier
to submit patches) would help the project a lot.
I guess I'm just a bit lazy, but something more welcoming on the trac
front-page along the line of "fix a bug now!" with a link to a ticket-report,
might be a good idea.
Writing this mail, i actually did have a look at the relevant link:
~ http://trac.edgewall.org/wiki/HowToContribute
and it appears the "helpwanted" is a bit abused? Eg:
~ http://trac.edgewall.org/ticket/3870
Should one interpret this as "we'd like more input on what to do" ?
Incidentally, I think the idea of using synchonous sending of messages is quite
flawed -- a better solution would probably be to rework the notification system
to use a pipe as standard, supplying a simple smpt/sendmail python-wrapper for
windows (which I think would be the only platform not having a sendmail-binary
by default). Note-to-self -- have a look at this later.
I certainly don't think the devs are hostile to fixes -- and I think a lot of
minor fixes could be contributed by large (larger) parts of the community -- if
only people was aware of where to start.
So far my personal experience have been that I've only fixed (plugin?)bugs I've
run into myself (which is fine, I guess) -- but that it's a bit of a bigger
hurdle to know where to start if I felt like spending a few hours helping the
trac project.
Best regards,
Eirik
(**) I *have* looked at the thunderbird sourcecode, and quickly abandoned all
hope of contributing fixes. Note, I don't think it's completely fair to assume
this is because their metodology is wrong -- I think it mostly just means that
the core mail functionality of Netscape Navigator could've benefited by
borrowing from mutt rather than reinventing the wheel in-house.
- --
~ .---. Eirik Schwenke <eirik.s...@nsd.uib.no>
( NSD ) Harald Hårfagresgate 29 Rom 150
~ '---' N-5007 Bergen tlf: (555) 889 13
~ GPG-key at pgp.mit.edu Id 0x8AA3392C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIX/Y9xUW7FIqjOSwRAl71AJ9Wmt84HJ/Y6F3J7Jp/7KMvnhwP3ACgs/Bb
OPqhG7EN9pYz2wlETWnSWMs=
=PsUR
-----END PGP SIGNATURE-----
Jani Tiainen
> Noah Kantrowitz wrote:
>>
>> On Jun 23, 2008, at 1:13 PM, Alec Thomas wrote:
>>
>>> 2008/6/24 Scott Bussinger <sco...@opto-pps.com>:
>>>>> Christian has made a very useful report on the popular tickets:
>>>>> http://trac.edgewall.org/report/32
>>>> This _is_ an interesting report. To make it truly useful though I
>>>> think would require two things:
>>>>
>>>> 1) Explicitly stating that development on the project is going to be
>>>> at least partially guided by the number of people who "vote" for a
>>>> feature request by entering themselves in the CC field.
>>>>
>>>>
>>>> 2) A definite show of support from the active developers on the
>>>> project to actually implement some of the popular features requested
>>>> (either in the core or as a supported plugin).
>>> I agree 100%. I think we need to shift to a model of actively trying
>>> to
>>> implement features users want. Workflow is a good example of this, but
>>> we need to continue.
>
> Ok, so you're saying that we currently focusing on unwanted features? ;)
Well maybe one of the reasons here is very very long release cycle
between 0.10.4 and 0.11. It really feels... focusing somewhere else... :D
> Seriously though. "Voting" and other forms of feature popularity
> indicators are good tools that we probably should use more.
>
> But we also need to remember that even if somehow half the internet
> voted on a particular feature doesn't automatically mean it's a good
> candidate to include in the next release or at all.
How about going middle way like we do in our business environment -
before every release we have community meeting where we propose set of
features for our product. There usually is one or two that we think is
"essential" and it will be included anyway. Then there is small set
(usually five) of possible candidates to vote for 2 or 3 of them _will_
get on release. Leftovers are kept in case someone really wants them and
we will sell it for extra money.
>> Can we install VotePlugin on t.e.o? I have a report to do summaries
>> using that instead and it might be clearer to people that those
>> numbers matter.
>
> Sure, why not it's a lot better than abusing the cc field. Is it
> possible to configure it to give each user (or email) a limited number
> of votes? I think you'll give your decisions a bit more thought if you
> know you can only vote on 5-10 tickets at a time.
IIRC bugzilla has (at least somewhere I've seen) this kind of "top 5 of
my issues" implementation. There you can have always 5 issues open and
based on that you might get your issue implemented - or not.
But this kind of voting system requires some more strict login system
and user accounting.
--
Jani Tiainen
Noah Kantrowitz
> Can we install VotePlugin on t.e.o? I have a report to do summaries
> using that instead and it might be clearer to people that those
> numbers matter.
This voting plugin is now enabled. Go and vote on your favorite (or
hated) tickets.
--Noah
Alec Thomas
> Can we install VotePlugin on t.e.o? I have a report to do summaries
> using that instead and it might be clearer to people that those
> numbers matter.
>
> SELECT p.value AS __color__,
> id AS ticket, sum(v.vote) as votes, summary, component, version,
> milestone, t.type AS type,
> owner, status,
> time AS created,
> changetime AS _changetime, description AS _description,
> reporter AS _reporter
> FROM ticket t, enum p, votes v
> WHERE status <> 'closed'
> AND p.name = t.priority AND p.type = 'priority'
> AND v.resource = 'ticket/' || id
> GROUP BY id, summary, component, version, milestone, t.type, owner,
> time,
> changetime, description, reporter, p.value, status
> ORDER BY votes DESC, milestone, t.type, time
http://trac.edgewall.org/report/34
Jani Tiainen
Well, I try post my patch against latest XMLRPC sources. (I tried this
at the morning but brand new tortoisesvn 1.5 gave me some troubles)
It contains abstract RPC backend that forms base of evertyhing. Then
there is protocol spesific frontends that main job is to translate
spesific calls to internal RPC wise calls this time either XMLRPC calls,
or JSON-RPC calls. Also you can enable/disable either (or both) of these
'built-in' protocols.
Now if you want to add new functionality only thing you need to do is
write to abstract backend - it will automatically create corresponding
JSON or XMLRPC calls/responses.
--
Jani Tiainen
Jani Tiainen
I attached generalization patch against latest xmlrpc trunk:
http://trac-hacks.org/ticket/3241
Feel free to test.
--
Jani Tiainen
andre...@gmail.com
what people would like most to be implemented into core.
andre...@gmail.com
{34} and another link to wiki:SeaChange/WhatUsersWant
Regards,
André
On Jun 24, 10:07 pm, "andref.d...@gmail.com" <andref.d...@gmail.com>
wrote:
Jeff Hammel
> > something of
> > think we
> > need to go back and challenge some of the things we "know" about our
> > users'
> > needs. Our user base has been growing... but I think it has been
> > growing in
> > different proportions to what it started as, so our user base as a
> > whole is
> > probably very different than it was.
>
> statistics as part of the install and upgrade processes. Data like
> installed plugins, number of users, size of wiki and ticket database,
> version control system in use, etc etc. We all kind of dislike the
> idea, as they usually turn into PR nightmares. What do all you non-
> Trac-developers think about this?
>
I'm +1 if this idea is easily doable, -1 if it turns into a PR nightmare and too much work for the $
jeff
k0s
verbose port of what AutoQuery does currently. See:
http://trac-hacks.org/attachment/ticket/3226/autoquery_patch_vs_r7289.txt
Please let me know if this is sufficient or if you want me to do any
clean up. Also, should I ticket this on t.e.o.?
(and of course, the patcher is welcome to make any improvements
necessary to my code)
thanks
Jeff Hammel
The Open Planning Project
http://topp.openplans.org
On Jun 20, 10:41 am, Jeff Hammel <jham...@openplans.org> wrote:
> On Sat, Jun 21, 2008 at 12:18:01AM +1000, Alec Thomas wrote:
>
> > 2008/6/20 andref.d...@gmail.com <andref.d...@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
Jeff Hammel
Thanks again.
Jeff
> !DSPAM:4014,486a8f22128502143011171!
>
Christopher Lenz
On 01.07.2008, at 22:11, Jeff Hammel wrote:
> Also, if I wasn't verbose enough about it in the first email, I'd
> love feedback on how to do anything I'm doing here better so that I
> can write better code in the future.
When asking for patch review on the mailing list, including the patch
inline would be helpful ;)
On the patch itself:
* What's the use case for configurable default query_args? Couldn't
the default options for the query module itself be reused instead, if
possible? Or just some sane default like all open tickets?
* The excluded_fields option refers to fields not included with Trac
core. This should probably default to an empty list instead, if it is
even necessary at all (note how I like to avoid adding config
options :P )
* The option group should probably be just "ticket" instead of
"autoquery"
* Don't use self.env.href, use req.href.
* The query_link thing is kind of brute force. Would be nicer to just
use the **kwargs of req.href to construct the URL qith query string
params. And it probably should be `query_link(owner=ticket.owner)`
instead of `query_link('owner', ticket.owner)`. It would probably be
possible to have query_link be just a partial binding of req.href.
* The template has two py:if="" directives that serve as if/else.
Should be using py:choose instead.
On a related note, I'd prefer if the links in the ticket properties
box (the yellow box) would be more subtle (I'm assuming they're the
default red right now), possibly even only really discoverable on
hover. Many pages in Trac have already gotten way to "linky"; at some
point you end up with content where every second word is a red link,
which is ugly and distracting :P
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Jeff Hammel
Thanks for the prompt reply. I've made a new patch which I'll include at the end of this mail. Its also here:
http://trac-hacks.org/attachment/ticket/3226/autoquery_patch_vs_r7302.txt
On Tue, Jul 01, 2008 at 10:35:01PM +0200, Christopher Lenz wrote:
>
> Hey Jeff,
>
> On 01.07.2008, at 22:11, Jeff Hammel wrote:
> > Also, if I wasn't verbose enough about it in the first email, I'd
> > love feedback on how to do anything I'm doing here better so that I
> > can write better code in the future.
>
> When asking for patch review on the mailing list, including the patch
> inline would be helpful ;)
Thanks. Will do so in the future.
> On the patch itself:
>
> * What's the use case for configurable default query_args? Couldn't
> the default options for the query module itself be reused instead, if
> possible? Or just some sane default like all open tickets?
Now I'm using [query]\ndefault_anonymous_query. Is that better? I don't want to use default_query as one of these fields is (by default) owner.
> * The excluded_fields option refers to fields not included with Trac
> core. This should probably default to an empty list instead, if it is
> even necessary at all (note how I like to avoid adding config
> options :P )
I've left this in for now. This is a solution to http://trac-hacks.org/ticket/3178 which is necessary since the timingandestimation plugin uses JS to markup the fields. A couple of alternatives here:
* take out the excluded_fields entirely; this will make the patch cleaner, but will break timingandestimation. If the patch is committed to core, then I'll ticket that plugin noting the issue and maybe try to make a patch.
* instead of having an option, just have these hard-coded fields with a "# XXX" noting the reason that this is here. Again, its probably worth alerting timingandestimation about this so we can kill this entirely.
> * The option group should probably be just "ticket" instead of
> "autoquery"
Done for excluded_fields, the only remaining option.
> * Don't use self.env.href, use req.href.
Done.
> * The query_link thing is kind of brute force. Would be nicer to just
> use the **kwargs of req.href to construct the URL qith query string
> params. And it probably should be `query_link(owner=ticket.owner)`
> instead of `query_link('owner', ticket.owner)`. It would probably be
> possible to have query_link be just a partial binding of req.href.
I've kept this as a function in web_ui.py, though it does feel a bit brute force. I haven't changed it to be (**kw) since it will always take one key, value pair. If its really better to have it use **kw, I can do this.
Also, maybe its better just to put this function in the template? Another alternative is just to markup the fields themselves and not bother with the function at all. Any thoughts on this?
> * The template has two py:if="" directives that serve as if/else.
> Should be using py:choose instead.
Done.
> On a related note, I'd prefer if the links in the ticket properties
> box (the yellow box) would be more subtle (I'm assuming they're the
> default red right now), possibly even only really discoverable on
> hover. Many pages in Trac have already gotten way to "linky"; at some
> point you end up with content where every second word is a red link,
> which is ugly and distracting :P
They are indeed the default red.
Just to play Devil's advocate, I don't mind super-linky pages and actually like them. But I'm not against making these links more subtle. Is there an existing class that I can use to make these more subtle? I don't mind adding a class, but I don't really have much aptitude for UI, so any CSS I would do probably wouldn't be wonderful. Still I can try if you like.
> Cheers,
> --
> Christopher Lenz
> cmlenz at gmx.de
> http://www.cmlenz.net/
Thanks again for looking at this. Please let me know any further improvements I can make to this. Patch follows signature
Jeff Hammel
The Open Planning Project
http://topp.openplans.org
Index: trac/ticket/web_ui.py
===================================================================
--- trac/ticket/web_ui.py (revision 7302)
+++ trac/ticket/web_ui.py (working copy)
@@ -26,7 +26,7 @@
from genshi.builder import tag
from trac.attachment import AttachmentModule
-from trac.config import BoolOption, Option, IntOption, _TRUE_VALUES
+from trac.config import BoolOption, Option, IntOption, ListOption, _TRUE_VALUES
from trac.core import *
from trac.mimeview.api import Mimeview, IContentConverter, Context
from trac.resource import Resource, get_resource_url, \
@@ -105,6 +105,10 @@
If set to 'default', this is equivalent to 'yes' for new environments
but keeps the old behavior for upgraded environments (i.e. 'no').
(''since 0.11'').""")
+
+ excluded_fields = ListOption('ticket', 'excluded_fields',
+ default=['estimatedhours', 'hours', 'totalhours'],
+ doc="fields to exclude from AutoQuery markup")
# IContentConverter methods
@@ -557,10 +561,20 @@
if preserve_newlines == 'default':
preserve_newlines = self.env.get_version(initial=True) >= 21 # 0.11
preserve_newlines = preserve_newlines in _TRUE_VALUES
+
+ def query_link(x, y):
+ query = req.href('query', **{x:y})
+ args = self.env.config.get('query', 'default_anonymous_query')
+ if args:
+ query = '%s&%s' % (query, args)
+ return query
+
return {'ticket': ticket,
'context': Context.from_request(req, ticket.resource,
absurls=absurls),
- 'preserve_newlines': preserve_newlines}
+ 'preserve_newlines': preserve_newlines,
+ 'query_link': query_link,
+ 'excluded_fields': self.excluded_fields }
def _toggle_cc(self, req, cc):
"""Return an (action, recipient) tuple corresponding to a change
Index: trac/ticket/templates/ticket.html
===================================================================
--- trac/ticket/templates/ticket.html (revision 7302)
+++ trac/ticket/templates/ticket.html (working copy)
@@ -44,6 +44,7 @@
</head>
<body>
+
<py:def function="commentref(prefix, cnum)">
<a href="#comment:$cnum">$prefix$cnum</a>
</py:def>
@@ -135,9 +136,16 @@
not in ('type', 'owner')]">
<tr>
<th id="h_reporter">Reported by:</th>
- <td headers="h_reporter" class="searchable">${authorinfo(ticket.reporter)}</td>
+ <td headers="h_reporter" class="searchable">
+ <a href="${query_link('reporter', ticket.reporter)}">
+ ${authorinfo(ticket.reporter)}
+ </a>
+ </td>
<th id="h_owner">Owned by:</th>
- <td headers="h_owner">${ticket.owner and authorinfo(ticket.owner) or ''}
+ <td headers="h_owner">
+ <a href="${query_link('owner', ticket.owner)}">
+ ${ticket.owner and authorinfo(ticket.owner) or ''}
+ </a>
</td>
</tr>
<tr py:for="row in group(fields, 2, lambda f: f.type != 'textarea')"
@@ -154,7 +162,21 @@
<py:if test="field">
<py:choose test="">
<py:when test="'rendered' in field">${field.rendered}</py:when>
- <py:otherwise>${ticket[field.name]}</py:otherwise>
+ <py:otherwise>
+ <py:if test="ticket[field.name]">
+ <py:choose test="field.name in excluded_fields">
+ <py:when test="False">
+
+ <a href="${query_link(field.name, ticket[field.name])}">
+ ${ticket[field.name]}
+ </a>
+ </py:when>
+ <py:when test="True">
+ ${ticket[field.name]}
+ </py:when>
+ </py:choose>
+ </py:if>
+ </py:otherwise>
</py:choose>
</py:if>
</td>
Colin Guthrie
> I really liked their custom field system: basically you could have 3
> types of fields: simple text (singleline), long text (multiline) and
> list of enumerations.
I wrote a patch for trac core a while back that allowed enumerated
custom field values but it was pointed out to me that this could be done
with a filter in a plugin. I used that for my ClientsPlugin and it works
fine.
For ad-hoc enumerated custom fields a general purpose plugin could be
written that does the filtering.
That said this could be a case of using a hammer to crack a walnut. For
my ClientsPlugin its fine to use the filter but for a general purpose
plugin, perhaps the small patch to core is worth it.
But then it's a good argument to keep things simple in the core seeing
as the plugin architecture is so powerful :)
Col
Christopher Lenz
> On Tue, Jul 01, 2008 at 10:35:01PM +0200, Christopher Lenz wrote:
>> On the patch itself:
>>
>> * What's the use case for configurable default query_args? Couldn't
>> the default options for the query module itself be reused instead, if
>> possible? Or just some sane default like all open tickets?
>
> Now I'm using [query]\ndefault_anonymous_query. Is that better? I
> don't want to use default_query as one of these fields is (by
> default) owner.
Good point. default_anonymous_query should work for now, we can also
switch to a separate config option, or even a sensible hard-coded
default, later if needed.
>> * The excluded_fields option refers to fields not included with Trac
>> core. This should probably default to an empty list instead, if it is
>> even necessary at all (note how I like to avoid adding config
>> options :P )
>
> I've left this in for now. This is a solution to http://trac-hacks.org/ticket/3178
> which is necessary since the timingandestimation plugin uses JS to
> markup the fields. A couple of alternatives here:
>
> * take out the excluded_fields entirely; this will make the patch
> cleaner, but will break timingandestimation. If the patch is
> committed to core, then I'll ticket that plugin noting the issue and
> maybe try to make a patch.
>
> * instead of having an option, just have these hard-coded fields
> with a "# XXX" noting the reason that this is here. Again, its
> probably worth alerting timingandestimation about this so we can
> kill this entirely.
Yeah, this really should be fixed in TimingAndEstimation. Providing an
excluded_fields option definitely makes sense, but the name needs
improvement as it sounds way too broad… maybe something like
"unlinked_fields" or such?
>> * The query_link thing is kind of brute force. Would be nicer to just
>> use the **kwargs of req.href to construct the URL qith query string
>> params. And it probably should be `query_link(owner=ticket.owner)`
>> instead of `query_link('owner', ticket.owner)`. It would probably be
>> possible to have query_link be just a partial binding of req.href.
>
> I've kept this as a function in web_ui.py, though it does feel a bit
> brute force. I haven't changed it to be (**kw) since it will always
> take one key, value pair. If its really better to have it use **kw,
> I can do this.
Makes sense.
> Also, maybe its better just to put this function in the template?
> Another alternative is just to markup the fields themselves and not
> bother with the function at all. Any thoughts on this?
On second though, the query_link stuff could probably be moved into
TicketModule._prepare_fields() and the template would just access
field members. That'd also move the excluded_fields logic out of the
template and into the controller. That feels slightly cleaner to me,
but no biggie either way.
>> On a related note, I'd prefer if the links in the ticket properties
>> sbox (the yellow box) would be more subtle (I'm assuming they're the
>> default red right now), possibly even only really discoverable on
>> hover. Many pages in Trac have already gotten way to "linky"; at some
>> point you end up with content where every second word is a red link,
>> which is ugly and distracting :P
>
> They are indeed the default red.
> Just to play Devil's advocate, I don't mind super-linky pages and
> actually like them. But I'm not against making these links more
> subtle. Is there an existing class that I can use to make these
> more subtle? I don't mind adding a class, but I don't really have
> much aptitude for UI, so any CSS I would do probably wouldn't be
> wonderful. Still I can try if you like.
Never mind, you can just leave this as is. I (or someone else) might
get a chance to make "non-essential" links more subtle sometime in the
future.
Thanks,
Jeff Hammel
>
> On 02.07.2008, at 17:49, Jeff Hammel wrote:
> > On Tue, Jul 01, 2008 at 10:35:01PM +0200, Christopher Lenz wrote:
> >> On the patch itself:
> >>
> >> * What's the use case for configurable default query_args? Couldn't
> >> the default options for the query module itself be reused instead, if
> >> possible? Or just some sane default like all open tickets?
> >
> > Now I'm using [query]\ndefault_anonymous_query. Is that better? I
> > don't want to use default_query as one of these fields is (by
> > default) owner.
>
> Good point. default_anonymous_query should work for now, we can also
> switch to a separate config option, or even a sensible hard-coded
> default, later if needed.
I'm neutral on whether this should be its own config option. Some trac admins might want this; to others, its just yet another config option that needs tweaking. So I can go either way.
> >> * The excluded_fields option refers to fields not included with Trac
> >> core. This should probably default to an empty list instead, if it is
> >> even necessary at all (note how I like to avoid adding config
> >> options :P )
> >
> > I've left this in for now. This is a solution to http://trac-hacks.org/ticket/3178
> > which is necessary since the timingandestimation plugin uses JS to
> > markup the fields. A couple of alternatives here:
> >
> > * take out the excluded_fields entirely; this will make the patch
> > cleaner, but will break timingandestimation. If the patch is
> > committed to core, then I'll ticket that plugin noting the issue and
> > maybe try to make a patch.
> >
> > * instead of having an option, just have these hard-coded fields
> > with a "# XXX" noting the reason that this is here. Again, its
> > probably worth alerting timingandestimation about this so we can
> > kill this entirely.
>
> Yeah, this really should be fixed in TimingAndEstimation. Providing an
> excluded_fields option definitely makes sense, but the name needs
> improvement as it sounds way too broad… maybe something like
> "unlinked_fields" or such?
Done, its now unlinked_fields. +1 on fixing it in TimingAndEstimation.
> >> * The query_link thing is kind of brute force. Would be nicer to just
> >> use the **kwargs of req.href to construct the URL qith query string
> >> params. And it probably should be `query_link(owner=ticket.owner)`
> >> instead of `query_link('owner', ticket.owner)`. It would probably be
> >> possible to have query_link be just a partial binding of req.href.
> >
> > I've kept this as a function in web_ui.py, though it does feel a bit
> > brute force. I haven't changed it to be (**kw) since it will always
> > take one key, value pair. If its really better to have it use **kw,
> > I can do this.
>
> Makes sense.
>
> > Also, maybe its better just to put this function in the template?
> > Another alternative is just to markup the fields themselves and not
> > bother with the function at all. Any thoughts on this?
>
> On second though, the query_link stuff could probably be moved into
> TicketModule._prepare_fields() and the template would just access
> field members. That'd also move the excluded_fields logic out of the
> template and into the controller. That feels slightly cleaner to me,
> but no biggie either way.
I've done this and it definately feels cleaner. All the logic now lives in web_ui.py and there are only two lines changed in the template (due to the owner and reporter fields being "special"). I'll paste the updated patch at EOM, or it is available here:
http://trac-hacks.org/attachment/ticket/3226/autoquery_patch_vs_r7349.txt
> >> On a related note, I'd prefer if the links in the ticket properties
> >> sbox (the yellow box) would be more subtle (I'm assuming they're the
> >> default red right now), possibly even only really discoverable on
> >> hover. Many pages in Trac have already gotten way to "linky"; at some
> >> point you end up with content where every second word is a red link,
> >> which is ugly and distracting :P
> >
> > They are indeed the default red.
> > Just to play Devil's advocate, I don't mind super-linky pages and
> > actually like them. But I'm not against making these links more
> > subtle. Is there an existing class that I can use to make these
> > more subtle? I don't mind adding a class, but I don't really have
> > much aptitude for UI, so any CSS I would do probably wouldn't be
> > wonderful. Still I can try if you like.
>
> Never mind, you can just leave this as is. I (or someone else) might
> get a chance to make "non-essential" links more subtle sometime in the
> future.
>
> Thanks,
> --
> Christopher Lenz
> cmlenz at gmx.de
> http://www.cmlenz.net/
Thank you. Keep me updated on the status here -- I'd love to see this in core.
Jeff
The patch:
Index: trac/ticket/web_ui.py
===================================================================
--- trac/ticket/web_ui.py (revision 7349)
+++ trac/ticket/web_ui.py (working copy)
@@ -26,7 +26,7 @@
from genshi.builder import tag
from trac.attachment import AttachmentModule
-from trac.config import BoolOption, Option, IntOption, _TRUE_VALUES
+from trac.config import BoolOption, Option, IntOption, ListOption, _TRUE_VALUES
from trac.core import *
from trac.mimeview.api import Mimeview, IContentConverter, Context
from trac.resource import Resource, get_resource_url, \
@@ -105,6 +105,10 @@
If set to 'default', this is equivalent to 'yes' for new environments
but keeps the old behavior for upgraded environments (i.e. 'no').
(''since 0.11'').""")
+
+ unlinked_fields = ListOption('ticket', 'unlinked_fields',
+ default=['estimatedhours', 'hours', 'totalhours'],
+ doc="fields to exclude from AutoQuery markup")
# IContentConverter methods
@@ -1029,6 +1033,14 @@
for key in field_changes:
ticket[key] = field_changes[key]['new']
+ def _query_link(self, req, name, value):
+ """return a link to /query with the appropriate name and value"""
+ query = req.href('query', **{name:value})
+ args = self.env.config.get('query', 'default_anonymous_query')
+ if args:
+ query = '%s&%s' % (query, args)
+ return tag.a(value, href=query)
+
def _prepare_fields(self, req, ticket):
context = Context.from_request(req, ticket.resource)
fields = []
@@ -1036,6 +1048,10 @@
name = field['name']
type_ = field['type']
+ # enable a link to custom query for the field
+ if name not in self.unlinked_fields:
+ field['rendered'] = self._query_link(req, name, ticket[name])
+
# per field settings
if name in ('summary', 'reporter', 'description', 'status',
'resolution'):
@@ -1226,7 +1242,9 @@
'attachments': AttachmentModule(self.env).attachment_data(context),
'action_controls': action_controls,
'action': selected_action,
- 'change_preview': change_preview
+ 'change_preview': change_preview,
+ 'reporter_link': self._query_link(req, 'reporter', ticket['reporter']),
+ 'owner_link': self._query_link(req, 'owner', ticket['owner'])
})
def rendered_changelog_entries(self, req, ticket, when=None):
Index: trac/ticket/templates/ticket.html
===================================================================
--- trac/ticket/templates/ticket.html (revision 7349)
+++ trac/ticket/templates/ticket.html (working copy)
@@ -135,9 +135,9 @@
not in ('type', 'owner')]">
<tr>
<th id="h_reporter">Reported by:</th>
- <td headers="h_reporter" class="searchable">${authorinfo(ticket.reporter)}</td>
+ <td headers="h_reporter" class="searchable">${reporter_link}</td>
<th id="h_owner">Owned by:</th>
- <td headers="h_owner">${ticket.owner and authorinfo(ticket.owner) or ''}
+ <td headers="h_owner">${owner_link}
k0s
core)
On Jul 15, 5:05 pm, Jeff Hammel <jham...@openplans.org> wrote:
> On Mon, Jul 14, 2008 at 07:12:48PM +0200, Christopher Lenz wrote:
>
> > On 02.07.2008, at 17:49, Jeff Hammel wrote:
> > > On Tue, Jul 01, 2008 at 10:35:01PM +0200, Christopher Lenz wrote:
> > >> On the patch itself:
>
> > >> * What's the use case for configurable default query_args? Couldn't
> > >> the default options for the query module itself be reused instead, if
> > >> possible? Or just some sane default like all open tickets?
>
> > > Now I'm using [query]\ndefault_anonymous_query. Is that better? I
> > > don't want to use default_query as one of these fields is (by
> > > default) owner.
>
> > Good point. default_anonymous_query should work for now, we can also
> > switch to a separate config option, or even a sensible hard-coded
> > default, later if needed.
>
> I'm neutral on whether this should be its own config option. Some trac admins might want this; to others, its just yet another config option that needs tweaking. So I can go either way.
>
>
>
> > >> * The excluded_fields option refers to fields not included with Trac
> > >> core. This should probably default to an empty list instead, if it is
> > >> even necessary at all (note how I like to avoid adding config
> > >> options :P )
>
k0s
looked good, but not sure if this is still on anyone's radar. Is this
going into core anytime soon?
IRC: jhammel, k0s
>
> > On 02.07.2008, at 17:49, Jeff Hammel wrote:
> > > On Tue, Jul 01, 2008 at 10:35:01PM +0200, Christopher Lenz wrote:
> > >> On the patch itself:
>
> > >> * What's the use case for configurable default query_args? Couldn't
> > >> the default options for the query module itself be reused instead, if
> > >> possible? Or just some sane default like all open tickets?
>
> > > Now I'm using [query]\ndefault_anonymous_query. Is that better? I
> > > don't want to use default_query as one of these fields is (by
> > > default) owner.
>
> > Good point. default_anonymous_query should work for now, we can also
> > switch to a separate config option, or even a sensible hard-coded
> > default, later if needed.
>
> I'm neutral on whether this should be its own config option. Some trac admins might want this; to others, its just yet another config option that needs tweaking. So I can go either way.
>
>
>
> > >> * The excluded_fields option refers to fields not included with Trac
> > >> core. This should probably default to an empty list instead, if it is
> > >> even necessary at all (note how I like to avoid adding config
> > >> options :P )
>