Report for dynamic variables
Richard Liao
To view a report for dynamic variables, for example:
SELECT id AS ticket,summary FROM ticket WHERE priority=$PRIORITY
We must define it as an argument in the report URL.
http://trac.edgewall.org/reports/14?PRIORITY=high
But ordinary users will not modify report URL as above.
Is there an easy way to view a report with dynamic variables for them?
If not, I think we should provide a plugin to do that:
1. Listen all report requests, search the report query string that
contains dynamic variables.
2. If find, return a page that let user set the dynamic variables instead.
3. After user set all required dynamic variables, send report URL
with these values.
Is that feasible?
Regards.
Erik Andersson
Easy way is to provide the link with the parameter in the report. I.e. when you click the report url in the report list you will receive an error message. Then press the url provided in the description of the report.
I use that in reports that are date based etc, having one report and links for each month, week etc.
Good luck.
Cheers / Erik
Richard Liao
> Hi
>
> Easy way is to provide the link with the parameter in the report. I.e. when
> you click the report url in the report list you will receive an error
> message. Then press the url provided in the description of the report.
>
> I use that in reports that are date based etc, having one report and links
> for each month, week etc.
>
I think we still need a more generic way to view a report that the
dynamic values for user select from trac itself, not by trac
administrators.
I have looked over report.py and other documents, but can't find any
interfaces to manipulate report, any suggestion?
BTW, according to trac wiki pages:
"The report module is being phased out in its current form."
So, should we make effort to report?
Christian Boos
> Hi,
>
> To view a report for dynamic variables, for example:
> SELECT id AS ticket,summary FROM ticket WHERE priority=$PRIORITY
>
> We must define it as an argument in the report URL.
> http://trac.edgewall.org/reports/14?PRIORITY=high
>
> But ordinary users will not modify report URL as above.
> Is there an easy way to view a report with dynamic variables for them?
>
See http://trac.edgewall.org/ticket/7135
> If not, I think we should provide a plugin to do that:
> 1. Listen all report requests, search the report query string that
> contains dynamic variables.
> 2. If find, return a page that let user set the dynamic variables instead.
> 3. After user set all required dynamic variables, send report URL
> with these values.
>
> Is that feasible?
>
That can be done on the report page itself, and shouldn't require a plugin.
-- Christian
Culapov Andrei
we implemented something exactly like this. Take a look
https://projects.optaros.com/trac/oforge/report/9
The code is in a plugin that offers support for multiple projects.
http://code.optaros.com/trac/oforge/browser/trunk/plugins/oforgeplugin
If you don't need all the functionality provided by this plugin you
can take only the code that offers suport for variables.
ReportVariableFiller(a request filter) -
http://code.optaros.com/trac/oforge/browser/trunk/plugins/oforgeplugin/oforge/web_ui.py#L58
ReportVariableTemplateInjecter( a stream filter) -
http://code.optaros.com/trac/oforge/browser/trunk/plugins/oforgeplugin/oforge/web_ui.py#L124
a template - http://code.optaros.com/trac/oforge/browser/trunk/plugins/oforgeplugin/oforge/templates/query-variables.html
Christian Boos
> Hi Richard,
> we implemented something exactly like this. Take a look
> https://projects.optaros.com/trac/oforge/report/9
>
401 :-)
Other than that, the code looks interesting and even more so the OForge
project.
However, for this particular feature, I think it would have made more
sense to write a patch against Trac, instead of writing a request filter
+ stream filter, as (to me at least) this issue looks more like a defect
of the report subsystem rather than an optional feature: if you don't
set the PRIORITY dynamic var, Trac reports an error page with no way to
specify that value, which is not terribly useful. A simple list of input
boxes for the missing variables would do, and plugins could still be
implemented if anything more fancy is needed.
-- Christian
Robert C Corsaro
> Hi Richard,
> we implemented something exactly like this. Take a look
> https://projects.optaros.com/trac/oforge/report/9
Robert C Corsaro
> Culapov Andrei wrote:
>> Hi Richard,
>> we implemented something exactly like this. Take a look
>> https://projects.optaros.com/trac/oforge/report/9
>>
>
> 401 :-)
>
> Other than that, the code looks interesting and even more so the OForge
> project.
If you would like to try implementing OForge we would give you a ton of
support.
João Toledo
(before the actual SQL) telling Trac which fields should be showed to
the user so he could fill them in before the query would be executed.
Something like this:
<report definition>
-- ## 1: Active Tickets ## --
--
-- * List all active tickets by priority.
-- * Color each row based on priority.
-- * If a ticket has been accepted, a '*' is appended after the
owner's name
{{{
INITIAL_DATE.label = Start from
INITIAL_DATE.type = DATE
END_DATE.label = Until
END_DATE.type = DATE
}}}
SELECT ...
FROM ticket t ...
WHERE ...
AND t.some_field BETWEEN $START_DATE AND $END_DATE;
</report definition>
When the user select this report, Trac identifies the special section
and asks for the "Start from" and "Until" dates before executing the
query.
Richard Liao
>
> Hi Richard,
> we implemented something exactly like this. Take a look
> https://projects.optaros.com/trac/oforge/report/9
>
> The code is in a plugin that offers support for multiple projects.
> http://code.optaros.com/trac/oforge/browser/trunk/plugins/oforgeplugin
>
> If you don't need all the functionality provided by this plugin you
> can take only the code that offers suport for variables.
> ReportVariableFiller(a request filter) -
> http://code.optaros.com/trac/oforge/browser/trunk/plugins/oforgeplugin/oforge/web_ui.py#L58
> ReportVariableTemplateInjecter( a stream filter) -
> http://code.optaros.com/trac/oforge/browser/trunk/plugins/oforgeplugin/oforge/web_ui.py#L124
> a template - http://code.optaros.com/trac/oforge/browser/trunk/plugins/oforgeplugin/oforge/templates/query-variables.html
>
And there is more than that.
Culapov Andrei
This is a nice feature to have in trac directly and I agree with you
that it's not a very good solution to have a request filter and a
stream filter for it. I think that patching the code is worst than
our solution because is hard to maintain. We want to benefit from the
latest developments in trac so we have to update our installation
often.
Noah Kantrowitz
> Hi Richard,
> This is a nice feature to have in trac directly and I agree with you
> that it's not a very good solution to have a request filter and a
> stream filter for it.
Uhhh, why not? The plugin system exists for exactly this reason. This
should be doable with just a request filter and some simple magic.
This sounds very much like a good case for a small plugin. I think
OForge and the link are bad ideas, plugins should be small and do one
thing (and do it well). That kind of huge collection of features might
be good for boxing up and shipping to people that want a turnkey
solution, but they aren't much use in the Trac community.
--Noah
Christian Boos
Funny, at the same time I was reading the above, the following update
came up on #31 (Ticket Dependency), about whether the MasterTicket
plugin should be considered to be a "fix" for this issue or not:
> Using third-party plugin for such essential functionality looks risky.
> What about migration path and compatibility issues? There is no guarantee
> on the future compatibility of MasterTickets and Trac.
> Besides, MasterTickets looks quite limited. Trac is great, I bet you can
> do better than that.
>
> I can't believe that Trac team avoided implementation of such essential
> feature for so long (this ticket is 4+ years old). I love Trac but it's
> unusable in large projects because of things like this. Sad.
Nicely put, I can't agree more.
Trac has a nice plugin system, and this has led some to think that every
single feature can be implemented as a plugin. It's certainly possible
from a technical point of view, but when the feature in question is a
central one, or even more so, when the feature is actually more about
fixing a (small) defective behavior (which I think is the case for this
particular issue of "fields for missing dynamic vars", in a few mails
above), creating a plugin for it is the wrong thing to do, IMO.
Installing a system which requires a dozen of plugins in order to
function properly is cumbersome. It simply doesn't give confidence in
the system, and requires a good deal of expertise in knowing which
plugins are really necessary and which should be avoided. So why would
you ever take care to install a plugin for such a small defect like in
this example, and face the associated risks? For the few people who
would do it, you'll have thousands which will hit the problem in the
"base" product and will just think it's not a well polished system (and
they'll be right). I think the time spent in building such a plugin
would have been better spent in writing a well-tested patch against the
core product. The obvious advantage being that in later releases, no one
will face the defective behavior again, and that the fix "melds" in, can
be tested and verified against any other improvement to come. Also, more
people get to know and work on the code, enabling its continuous
improvement in quality. By doing it as a plugin, you're on your own and
you build on a weak foundation instead of strengthening it. But of
course you don't need to wait for someone to check in your patch, and
you don't have to struggle with an unresponsive (if not hostile)
development team, so it's the path of least resistance.
I hope nobody gets me wrong: there's no questions that there are great
Trac plugins out there, but those are rather adding new sub-systems,
enabling connectivity with external systems or such things. But plugins
which are addressing base functionality of existing subsystems or are
merely there for fixing defects in Trac can rather be considered as
"hacks". I never subscribed to this approach, but apparently I've been
in the minority and I've given up to try to change this course of action.
Now to answer the question "why has the Trac team avoided implementation
of such essential feature (#31) for 4 years", it's quite simple: the
TracCrossReferences effort which was started (3 years ago) to address
that issue, among other things, didn't get any "traction", quite to the
contrary, so it ended up in a branch which I stopped maintaining after a
while. People here at one hand are striving for "perfection", so any
incremental approach is considered very suspiciously, but on the other
hand, as soon as it's outside of Trac, it's "free for all" and any kind
of crude hack will do... No wonder some are answering "do it as a
plugin!" to /every/ attempt to raise a discussion about improving the
fundamentals of Trac itself, to the point there's almost no more
development discussion on this list.
Well, as you might have guessed by now, I've grown tired of this, and
0.11 will likely be my last Trac release, while I'm looking for ways to
build an enhanced, more cohesive solution, in line with my ideas (this
might succeed or not, but at least I won't have the feeling to bump into
walls).
-- Christian
Jeroen Ruigrok van der Werven
>Installing a system which requires a dozen of plugins in order to
>function properly is cumbersome.
Agreed with the notion that we do need to be selective of what goes in and
what not. There's a large area between nihilist and kitchen sink.
[On #31]
I fully agree that this is a functionality we *need* in Trac, users who do
not need the functionality will simply not use it, whereas other people (and
quite a lot) have been asking for the feature for a long time now. Either we
do it or we don't, but it is high time some definite answer with regard to
this.
With regard to MasterTickets, just blocks/blocked by will not cut it, in my
opinion, since the feature of parent/child is an essential one for quite a
many of our users. And as such the suggestion of Noah to close #31 since
MasterTickets is usable and stable does not reflect the request of the
ticket.
>Well, as you might have guessed by now, I've grown tired of this, and
>0.11 will likely be my last Trac release, while I'm looking for ways to
>build an enhanced, more cohesive solution, in line with my ideas (this
>might succeed or not, but at least I won't have the feeling to bump into
>walls).
Contrary to our recent spat, I do value you work and would hope we can get
this resolved since I agree with at least part of your vision (although I do
not know the entirety).
Personally I believe that the nihilist stance of Trac will hurt the project
in the end. On the other hand I am also keenly aware that a kitchen sink
approach will not be beneficial either. So we need to strike a balance.
I guess it will have to come down to a voting for the feature set of base
Trac.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフãƒãƒƒã‚¯ ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
My greatest fear... Is that all my Memories will be lost... Like
tears, in the rain...
Emmanuel Blot
>>0.11 will likely be my last Trac release, while I'm looking for ways to
>>build an enhanced, more cohesive solution, in line with my ideas (this
>>might succeed or not, but at least I won't have the feeling to bump into
>>walls).
>
> Contrary to our recent spat, I do value you work and would hope we can get
> this resolved since I agree with at least part of your vision (although I do
> not know the entirety).
>
> Trac.
I can't agree more on both this point, especially the first one.
> Personally I believe that the nihilist stance of Trac will hurt the project
> in the end. On the other hand I am also keenly aware that a kitchen sink
> approach will not be beneficial either. So we need to strike a balance.
From my perspective, one of the most impressive key feature of Trac is
its ease of use and clean-and-lean UI. Compare to many other bug
tracking tool, Trac has a simple, yet powerful interface. Many users
simply do not use / want to use a bug tracking tool because there are
too many fields offer to them to fill in / to find the right ones.
The plugin architecture allows to easily enable/disable feature, so
maybe we could bundle key features (such as the "MasterPlugin") into
Trac standard delivery, but provide an installation option to select
which features are enabled and which are disabled / hidden. An admin
could choose among several installation kinds, without having to
install tons of plugins and to deal with dependencies and API breaks.
Anyway I do hope Christian won't fork away from the mainstream Trac
Cheers,
Manu
Jeroen Ruigrok van der Werven
>From my perspective, one of the most impressive key feature of Trac is
>its ease of use and clean-and-lean UI. Compare to many other bug
>tracking tool, Trac has a simple, yet powerful interface. Many users
>simply do not use / want to use a bug tracking tool because there are
>too many fields offer to them to fill in / to find the right ones.
Right, but I do not see how child/parent, blocks/blocked by, and such
relationships will be required for the user. They are some of an
administrative issue and if a user registers a ticket and we subsequently
hang it under a specific parent ticket it will only be a field displayed on
viewing the ticket, not on entering. So I think that is sort of a non-issue.
With regard to the UI, I agree, but at the same time we are also not making
full use of the browser's full width given to us. I do not think I am alone
in having a wide screen lcd monitor nowadays and even using my browser at
half the width of the monitor the Trac ticket data cuts that available width
in half. Not entirely useful in some ways.
>The plugin architecture allows to easily enable/disable feature, so
>maybe we could bundle key features (such as the "MasterPlugin") into
>Trac standard delivery, but provide an installation option to select
>which features are enabled and which are disabled / hidden. An admin
>could choose among several installation kinds, without having to
>install tons of plugins and to deal with dependencies and API breaks.
I am not sure if I am more in favour of adding some key feature
functionality into Trac proper or putting it in a default added plugin. It
also depends on its development since it does make a difference a bit
whether it's maintained in the main repository or somewhere else.
The question still remains: what feature set?
Bobbysmith007
A little background:
I maintain the TimingAndEstimationPlugin (http://trac-hacks.org/wiki/
TimingAndEstimationPlugin), which seems to be fairly widely adopted
for people who want to track their time with Trac. I wrote the first
version of this plugin against trac 9 with a first release sometime
near trac 10's release.
My preferred route for functionality like this (and MasterTicket /
Dynamic Report Variables / etc) would be to bless some plugins with
auto inclusion into the trac install (disabled by default). I greatly
value that trac is simple to use. I recently helped teach a Software
Engineering class that made use of trac. I feel that it could not
have been used if it was more toward the bugzilla side of issue
tracking (way too complex for a first go at software management).
That said, part of the project was to estimate and track time (which
is convenient since I wrote the plugin). I am sure that others will
want to have only ticket dependancies and not time tracking, or only
custom reports with a variable filling form. All of these are
essential for the group of users that need them and the system cannot
be complete without them. By blessing and including these plugins
with trac we can keep the simplicity, while easily enabling plugins
that fill out the functionality we need.
One thought I have been kicking around is a package management plugin
for trac that would be able download and install a plugin and update
trac from the web admin screen. But this would really need to be
included in Trac (or as a blessed / pre-included plugin) to alleviate
the same frustrations that users are expressing in this thread. With
a package manager and "blessed" plugins, I think that the
disagreements over what functionality should be included by default
can be mitigated to some extent.
Cheers,
Russ
Noah Kantrowitz
> My preferred route for functionality like this (and MasterTicket /
> Dynamic Report Variables / etc) would be to bless some plugins with
> auto inclusion into the trac install (disabled by default). I greatly
> value that trac is simple to use. I recently helped teach a Software
> Engineering class that made use of trac. I feel that it could not
> have been used if it was more toward the bugzilla side of issue
> tracking (way too complex for a first go at software management).
> That said, part of the project was to estimate and track time (which
> is convenient since I wrote the plugin). I am sure that others will
> want to have only ticket dependancies and not time tracking, or only
> custom reports with a variable filling form. All of these are
> essential for the group of users that need them and the system cannot
> be complete without them. By blessing and including these plugins
> with trac we can keep the simplicity, while easily enabling plugins
> that fill out the functionality we need.
I agree with this approach. Keep the Trac codebase small, and just bundle
snapshots of some plugins (perhaps determined by community voting once t-h
gets moved to 0.11) along with a set of release media. If people want new
versions of those plugins, they can upgrade, but this is enough of a stopgap
until ...
> One thought I have been kicking around is a package management plugin
> for trac that would be able download and install a plugin and update
> trac from the web admin screen. But this would really need to be
> included in Trac (or as a blessed / pre-included plugin) to alleviate
> the same frustrations that users are expressing in this thread. With
> a package manager and "blessed" plugins, I think that the
> disagreements over what functionality should be included by default
> can be mitigated to some extent.
... we really fix the problem with a 1-click plugin installer. I have been
working on this for quite a while now, and have hit a large number of brick
walls. The short version is that we need to fork PyPI (TracPI or something)
because I can't get the catalog-sig to acknowledge any patches I send them.
This would be a part of the long-fabled trac-hacks++ Alec and I have been
discussing over the last year or so. I think this installer will solve the
_real_ problem people are having. Its not that lots of plugins are a bad
idea, they are just annoying to get working. Put this installer in Trac
core, and you get the experience I think everyone wants.
--Noah
Risto Kankkunen
milestone. We have a number of reports to see how we are doing and
they take the milestone as a parameter. For each milestone I make the
milestone page contain links to the reports with the correct milestone
parameter.
Copy/pasting the previous milestone page and updating the parameters
every month has become a bit boring, though. I wish I could somehow
set the MILESTONE variable once in the page. Better yet, I wish I
could include the page template giving the MILESTONE as an argument to
the page!
Anyone working on something like this? (I've been waiting for 0.11
before considering any enhancements on my own...)
(Tangentially, I once saw a Google video about XWiki (most likely this
one: http://video.google.com/videoplay?docid=5378069710554665586) and
really felt excited that every XWiki page is an object of some class
with well defined attributes, classes being like page templates.
http://platform.xwiki.org/xwiki/bin/view/DevGuide/ E.g. having an
address book page template with fields 'Name', 'Phone' and 'Address' I
could be sure that every page made from that template has those
fields. I constantly face situations where it would be handy to have a
bit more structure on wiki pages without going into databases.)
Mikhail
>
> ... we really fix the problem with a 1-click plugin installer. I have been
.
.
> idea, they are just annoying to get working. Put this installer in Trac
> core, and you get the experience I think everyone wants.
>
And it is called DLL, pardon, plugin hell ;-(
To avoid this hell the most popular plugins should be maintained together with
the core Trac. And then - why make them plugins? Just make them part of the core
and provide an option to turn them off if someone is picky about unused
functionality. IMHO a system that requires too much tuneup will not survive these
days because most people are too busy with their regular work/fun to search for
and manage all these useful plugins. Someday someone will create an alternative
application that has all the needed functionality by default and users will vote
by their feet. Imagine Python distribution without standard library or Linux
without X or gcc.
Regards,
Mikhail
P.S. I think Joel had a very good article on importance of defaults in software,
can't find the link right now though.
Noah Kantrowitz
> -----Original Message-----
> From: trac...@googlegroups.com [mailto:trac...@googlegroups.com] On
> Behalf Of Mikhail
> Sent: Friday, May 30, 2008 1:02 PM
> To: trac...@googlegroups.com
> Subject: [Trac-dev] Re: Feature set [was: Re: [Trac-dev] Re: Report for
> dynamic variables]
>
>
> Noah Kantrowitz <noah <at> coderanger.net> writes:
> >
> > ... we really fix the problem with a 1-click plugin installer. I have
> been
> .
> .
> .
> > idea, they are just annoying to get working. Put this installer in
> Trac
> > core, and you get the experience I think everyone wants.
> >
>
> And it is called DLL, pardon, plugin hell ;-(
Not sure who DLLs are related to this. DLL Hell is a loading paths issue ...
> To avoid this hell the most popular plugins should be maintained
> together with
> the core Trac. And then - why make them plugins? Just make them part of
> the core
> and provide an option to turn them off if someone is picky about unused
> functionality.
The current dev team is taxed enough as is maintain the current codebase and
adding new features we all seem to agree on. As code size increases, effort
goes up in a very non-linear fashion. Two small codebases are much easier to
maintain and work with than one bigger one.
IMHO a system that requires too much tuneup will not
> survive these
> days because most people are too busy with their regular work/fun to
> search for
> and manage all these useful plugins. Someday someone will create an
> alternative
> application that has all the needed functionality by default and users
> will vote
> by their feet. Imagine Python distribution without standard library or
> Linux
> without X or gcc.
Now imagine a Python where the core python team maintained all the standard
libraries and everything was built together in one big interpreter. Most of
the new libraries being added to the std lib are external packages that they
just snapshot when making releases (ctypes, pysqlite, etc). They are still
developed independently.
I don't think things like ticket dependencies are such crucial features that
putting them behind a single checkbox is a bad idea. I would rather that
checkbox pull in a plugin than just enable built-in functionality, since it
will be transparent either way.
--Noah
Risto Kankkunen
> > core, and you get the experience I think everyone wants.
>
> And it is called DLL, pardon, plugin hell ;-(
its path to success: the core product cannot (and should not) please
everyone and with extensions everyone can still make the product do
what they need.
The problem I've had with Trac plugins so far is that there are a
couple of interesting plugins that state their 0.10 version is broken
(by design) and will not fixed until version 0.11, but version 0.11
has been so slow to materialize. The more Trac starts to rely on
plugins, the more the core team needs to think about the release cycle
and APIs rather than core features. So it's not the new features that
define a new feature but rather the new or changed interfaces. Core
feature development can be then done incrementally during the lifetime
of the new interface set in sub-releases 0.11.1, 0.11.2 etc.
krkempa
point.
Noah's wrote:
> That kind of huge collection of features might
> be good for boxing up and shipping to people that want a turnkey
> solution, but they aren't much use in the Trac community
dirty and be ready for using hacks everywhere... Noah's statement is
one of the most ridiculous I've ever read.
Noah, usually people have to deal with a bunch of different systems
and have many problems to solve. It's naturally that the best approach
here is to limit the effort which is needed for maintenance of a
single tool. Why somebody should give a f*** on a tool who increases
amount of job that needs to be done?
When I read this I'm starting to perceive that Trac is now in the
wrong hands. Noah, please. Grow up.
Cboos, I wish you all good with the new project, but duplicating
effort to bring a good tool (as I perceived Trac until recenty) is a
dramatic waste of time. Maybe it's just a problem with management of
Trac as a software product. Democracy is not always the best thing in
such situations :)
Jonas Borgström
> Noah's wrote:
>> That kind of huge collection of features might
>> be good for boxing up and shipping to people that want a turnkey
>> solution, but they aren't much use in the Trac community
>
> So anyone who want to have usable Trac flavour needs to make his hand
> dirty and be ready for using hacks everywhere... Noah's statement is
> one of the most ridiculous I've ever read.
Even if we doubled the trac-core code base by including the 10 or so
most popular plugins chances are good that you would be able to find
other plugins that would make Trac more usable for you.
There is no magic set of plugins that would make Trac perfect for
everyone and all the different ways Trac is used.
For this issue with dynamic variables for reports I think it has a good
chance of making it into trac core. But starting with a plugin based
implementation is probably a good approach both since it will solve the
reporters immediate problem and also give it a chance to "prove itself"
before inclusion.
/ Jonas
Mike
>> >
>> > ... we really fix the problem with a 1-click plugin installer. I have
>> been
>> .
>> Trac
>> > core, and you get the experience I think everyone wants.
>> >
>>
>> And it is called DLL, pardon, plugin hell ;-(
>
> Not sure who DLLs are related to this. DLL Hell is a loading paths issue ...
> The current dev team is taxed enough as is maintain the current codebase and
> adding new features we all seem to agree on. As code size increases, effort
on the contrary - kudos to all of you for the very useful product!
The current team is too busy to add new features and do releases but,
frankly
speaking, the code base is too small to attract new members. All the
main areas
are taken and, as the recent disscussion on this list shows, you guys
step on each
others toes already.
At the same time you are too conservative in extending the project and
in adding
new functionality which could bring in new members. This is not an
easy problem
and good luck in solving it - you are the only ones who could do it.
> goes up in a very non-linear fashion. Two small codebases are much easier to
> maintain and work with than one bigger one.
>
'non-linear fashion'
would be true, then the number of core gcc developers for example (in
comparizon to
Trac) would be gazilion times larger than it is now.
The recent fight with memory leak in Genshi shows that, even if the
core members of
the two projects are almost the same, the administrative overhead is
big.
> Now imagine a Python where the core python team maintained all the standard
> libraries and everything was built together in one big interpreter. Most of
> the new libraries being added to the std lib are external packages that they
> just snapshot when making releases (ctypes, pysqlite, etc). They are still
> developed independently.
>
a part of the official
Python tree :) Of course there is always a transition period when it
is better to separate
development of some new subsystem and the larger subsystem the larger
this period.
But this is not the point. The point is that such modules as glob,
getopt, difflib etc. are in
the stdlib! And their maintenance is much easier because of that - the
common unit tests
will catch any inconsistency.
Another point is that in many cases the plugin's in question code size
is ridiculously small
but the functionality is a common place in other systems - take the
WikiRename plugin for
example. Maintaining it separately is a waste of time IMHO.
Look at the trac-hacks - how many plugins are updated to 0.11? How
many of these
updated are updated/mantained by the core developers? Yet another
point is that core
developers are loaded by the plugins maintenance anyway.
> I don't think things like ticket dependencies are such crucial features that
> putting them behind a single checkbox is a bad idea. I would rather that
> checkbox pull in a plugin than just enable built-in functionality, since it
> will be transparent either way.
>
is
always available.
You said it yourself in another message that 'putting them behind a
single checkbox' is not
an easy task. Forking PyPi would be the same scale project as the Trac
itself.
Also note that not all environments would allow software installation
on a server through
the WEB - this is a serious security problem.
It would be interesting to gather somehow the information on what is
the average number
of plugins used in Trac installations.
Regards,
Mikhail
Noah Kantrowitz
Also a good point, there are certainly plugins that reach a point
where they are both widely used and they are "stable", meaning the
problem space has bee worked out well and the solution chosen by the
plugin does what it needs to. These plugins are great candidates for
core inclusion (WebAdmin, TicketDelete, parts of AccountManager, etc
etc).
To answer the issue with API breakage and lack of maintainers:
1) Trac is pre-1.0. We take this somewhat seriously as meaning that we
still reserve the right to break APIs as needed. We do try to keep
backwards compatibility for at least one major version, but this is
not always possible. If you want to wait for Trac 1.0, any plugin
written for that should work for a very very long time. This is up to
you. Compared to many other projects in the same area (bugzilla, jira,
roundup) Trac is still very young. There are many parts of it that the
dev team knows are poorly done, just takes time to fix. Also just for
the record, if you install both ClearSilver and the old WebAdmin, a
very large number of 0.10 plugins will run on 0.11 without modification.
2) People not maintaing plugins is a hard problem, but one I think is
out of scope for the Trac core project. Having better community rating
and feedback systems on trac-hacks would at least give some indication
as to if a hack contributor is likely to vanish, but even this is not
perfect. Saying it should be in core, so you don't run the risk of the
maintain vanishing is also foolish, as we do have core devs phase in
and out of activity a good bit too. The best way I know of to help
with this issue is to roll up your sleeves and help, submit patches
when things are broken. If you find a plugin on trac-hacks that looks
abandoned, try contacting the author, if they are okay with it (or if
they have vanished), Alec or I can transfer ownership of plugins on
trac-hacks so new people can take over. I am all ears if people have
suggestions for community management too.
--Noah
Mike
> > > idea, they are just annoying to get working. Put this installer in Trac
> > > core, and you get the experience I think everyone wants.
>
> > And it is called DLL, pardon, plugin hell ;-(
>
> Like with Firefox and its extenstions? I thought extensions have been
> its path to success: the core product cannot (and should not) please
> everyone and with extensions everyone can still make the product do
> what they need.
>
and
nobody wants for Trac to please all.
Trac and FireFox are very different animals:
- FireFox is an end user application. You can do whatever you please
with
it - it is on yours computer. Besides that FireFox as a web browser is
feature
complete - you need no extensions to browse the web and it has a lot
of
additional convenience features for that out of the box. Imagine if
such a
not exactly needed for web browsing features as bookmarks, history,
navigation panel etc. would be needed to be downloaded and installed
separately :).
Would you prefer such a browser to the current FireFox?
- Trac is a server side application for a project development and
management.
Of course if you use it for your home pet project you can run it on
you
development machine and install/remove whatever you want at any time.
But if you use it for the team of developers and for a big enough
project or
even several projects then it is completely different. In this case
you better put
Trac on a server machine, pay attention to security, backups etc. In
this case
Trac is not a toy for a computer kiddy anymore, it should obey to the
common
rules for a server side application. Try to talk to you IT people and
see whould
they allow you to install/update plugins with a point and click
through the web
and if yes then what requirements should be met in every such case.
And to the contrary to FireFox, almost all Trac installations use
plugins to fulfill
the core functionality - rename/navigate/tag wiki pages, customize/
query tickets,
etc. It is just plain inconvenient.
> The problem I've had with Trac plugins so far is that there are a
> couple of interesting plugins that state their 0.10 version is broken
> (by design) and will not fixed until version 0.11, but version 0.11
> has been so slow to materialize. The more Trac starts to rely on
> plugins, the more the core team needs to think about the release cycle
the more such a "broken by design" interesting plugins you will
encounter ;)
As a side note - look at the side bar on http://www.trac-hacks.org/
<<start quote>>
Upgrading TracHacks to 0.11 ¶
TracHacks will be intermittently offline over the next week or so
while I upgrade to Trac 0.11.
<<end quote>>
The main Trac plugins repository requires 'week or so' to upgrade! I
think that the main
reason for that is "The Trac Plugins Hell".
Mike
> thing (and do it well). That kind of huge collection of features might
> be good for boxing up and shipping to people that want a turnkey
> solution, but they aren't much use in the Trac community.
>
(and probably not the last) time this topic comes afloat means
that "Trac community".
Noah Kantrowitz
The simple plugin installer would also be integrated with trac-admin
(trac-admin ... install tags, perhaps). I just like GUIs so thats what
I have written first.
>
> and if yes then what requirements should be met in every such case.
> And to the contrary to FireFox, almost all Trac installations use
> plugins to fulfill
> the core functionality - rename/navigate/tag wiki pages, customize/
> query tickets,
> etc. It is just plain inconvenient.
What is considered a "core feature" differs for people. Trac core
provides the lowest common denominator. There are times when a plugin
needs to be integrated, as I mentioned in an earlier email, and then
we should go ahead and do that. These cases have been pretty rare so
far though. The fact that you included wiki tags as a core feature
illustrates this pretty well, I'm sure there are plenty of people on
this list that don't care at all about tags.
>
>
>> The problem I've had with Trac plugins so far is that there are a
>> couple of interesting plugins that state their 0.10 version is broken
>> (by design) and will not fixed until version 0.11, but version 0.11
>
> I like this term - "broken by design" - that is a real pearl!
The only plugin I know of that fits this is MasterTickets, and yes the
design I picked for the 0.10 version turned out poorly. To say I
purposefully picked a bad design is quite silly. I did a massive
rework when I ported to 0.11 and it works much better. This is how
development works, you try to improve things.
>
>
>> has been so slow to materialize. The more Trac starts to rely on
>> plugins, the more the core team needs to think about the release
>> cycle
>
> And unless these plugins will be maintained inside the core code base
> the more such a "broken by design" interesting plugins you will
> encounter ;)
>
> As a side note - look at the side bar on http://www.trac-hacks.org/
> <<start quote>>
> Upgrading TracHacks to 0.11 ¶
>
> TracHacks will be intermittently offline over the next week or so
> while I upgrade to Trac 0.11.
> <<end quote>>
> The main Trac plugins repository requires 'week or so' to upgrade! I
> think that the main
> reason for that is "The Trac Plugins Hell".
No, the reason for this is that both Alec and I have real lives and
lots of other things to do. Its just a question of finding time to do
a server upgrade.
--Noah
Christopher Lenz
On 30.05.2008, at 11:00, Christian Boos wrote:
>> Using third-party plugin for such essential functionality looks
>> risky.
>> What about migration path and compatibility issues? There is no
>> guarantee
>> on the future compatibility of MasterTickets and Trac.
>> Besides, MasterTickets looks quite limited. Trac is great, I bet
>> you can
>> do better than that.
>>
>> I can't believe that Trac team avoided implementation of such
>> essential
>> feature for so long (this ticket is 4+ years old). I love Trac but
>> it's
>> unusable in large projects because of things like this. Sad.
>
> Nicely put, I can't agree more.
In principal I agree, too. But it should be noted that, while the
ticket is 4 years old, there's exactly ONE patch attached to it (two
if you count the xref branch). Why?
This is an open source project, none of the folks on the "core team"
get paid to work on features other people need. So for such hugely
popular feature requests, we really depend on the people who need the
features to step up and do some of the dirty work, or hire someone to
do it for them.
> Trac has a nice plugin system, and this has led some to think that
> every
> single feature can be implemented as a plugin. It's certainly possible
> from a technical point of view, but when the feature in question is a
> central one, or even more so, when the feature is actually more about
> fixing a (small) defective behavior (which I think is the case for
> this
> particular issue of "fields for missing dynamic vars", in a few mails
> above), creating a plugin for it is the wrong thing to do, IMO.
This I agree with 100%. Another example is ticket deletion and backing
out ticket changes. There's the TicketDelete plugin that kinda sorta
works for this, but it should have been integrated (in improved form)
into Trac proper ages ago.
> Installing a system which requires a dozen of plugins in order to
> function properly is cumbersome.
"Function properly" is of course highly subjective. Many people would
claim that time tracking and/or master/sub-tickets are required
features for an issue tracker to function properly. For many others,
those features would only get in the way. And as the Trac mantra has
always been to "stay out of your way", the *tendency* has been to keep
such features out of the core, but enable their implementation as
extensions.
If by "function properly" you mean that defects such as the one that
started this thread are fixed, then I absolutely agree.
> It simply doesn't give confidence in
> the system, and requires a good deal of expertise in knowing which
> plugins are really necessary and which should be avoided. So why would
> you ever take care to install a plugin for such a small defect like in
> this example, and face the associated risks? For the few people who
> would do it, you'll have thousands which will hit the problem in the
> "base" product and will just think it's not a well polished system
> (and
> they'll be right). I think the time spent in building such a plugin
> would have been better spent in writing a well-tested patch against
> the
> core product. The obvious advantage being that in later releases, no
> one
> will face the defective behavior again, and that the fix "melds" in,
> can
> be tested and verified against any other improvement to come. Also,
> more
> people get to know and work on the code, enabling its continuous
> improvement in quality. By doing it as a plugin, you're on your own
> and
> you build on a weak foundation instead of strengthening it. But of
> course you don't need to wait for someone to check in your patch, and
> you don't have to struggle with an unresponsive (if not hostile)
> development team, so it's the path of least resistance.
Agreed.
> I hope nobody gets me wrong: there's no questions that there are great
> Trac plugins out there, but those are rather adding new sub-systems,
> enabling connectivity with external systems or such things. But
> plugins
> which are addressing base functionality of existing subsystems or are
> merely there for fixing defects in Trac can rather be considered as
> "hacks". I never subscribed to this approach, but apparently I've been
> in the minority and I've given up to try to change this course of
> action.
Again, "base functionality" is subjective, agreed otherwise.
> Now to answer the question "why has the Trac team avoided
> implementation
> of such essential feature (#31) for 4 years", it's quite simple: the
> TracCrossReferences effort which was started (3 years ago) to address
> that issue, among other things, didn't get any "traction", quite to
> the
> contrary, so it ended up in a branch which I stopped maintaining
> after a
> while.
You make it sound like the xref approach was the only way to get
ticket dependencies into Trac. From my point of view, it was a very
broad design ("among other things") bordering on over-engineering.
There was never substantial opposition against implementing ticket
dependencies in a more straight-forward way. In fact, ticket #31 was
created by one of the original authors of Trac in the very early days.
I personally do think we should have ticket dependencies, and some
others have expressed the same opinion.
> People here at one hand are striving for "perfection", so any
> incremental approach is considered very suspiciously,
I don't understand how striving for perfection conflicts with
incremental development. Surely, a patchwork of incremental
enhancements and fixes done without a common vision or design is not a
good approach, and leads to an increasingly convoluted code base. I'm
all for the evolutionary development of software, but it needs to be
guided by design goals and quality standards in terms of API evolution.
> but on the other
> hand, as soon as it's outside of Trac, it's "free for all" and any
> kind
> of crude hack will do... No wonder some are answering "do it as a
> plugin!" to /every/ attempt to raise a discussion about improving the
> fundamentals of Trac itself, to the point there's almost no more
> development discussion on this list.
This I agree with. There are quite a number of things where we should
seriously consider whether they'd be better fixed/enhanced in Trac
proper rather than moved out into a "Trac Hack".
> Well, as you might have guessed by now, I've grown tired of this, and
> 0.11 will likely be my last Trac release, while I'm looking for ways
> to
> build an enhanced, more cohesive solution, in line with my ideas (this
> might succeed or not, but at least I won't have the feeling to bump
> into
> walls).
I find this part somewhat misleading.
By closing #31 and referencing this thread for dramatic effect or some
kind of PR stunt, you make it look like the Trac team does not
actually want to add ticket dependencies, but you do, so you want to
fork. The thing is, there has AFAIK never been consensus that Trac
should *not* have ticket dependencies in core. Noah suggested the
ticket *could* be closed with reference to MasterTickets, but he
didn't actually close it. You did.
While I suppose there's some level of conflict between your preference
to have more things in core, and the preference of some others to keep
the core lean and simple, this is IMHO far overshadowed by the
conflict over the long-term design (xref, GenericTrac, etc).
Any disagreements on core vs plugin can really be sorted out on a case-
by-case basis, as long as we can all agree on the basic mantra that
got Trac so popular in the first place. The following sentences have
been on the homepage of the Trac project pretty much since day one:
"Trac uses a minimalistic approach to web-based software project
management. Our mission is to help developers write great software
while staying out of the way. Trac should impose as little as possible
on a team's established development process and policies."
That mantra does *not* mean Trac should not have ticket dependencies,
or any other feature in particular. It just means that by default, we
want to avoid ending up with a system that is too complex for people
to use comfortably. And we certainly want to avoid imposing too much
process on software projects.
A conflict in the long-term goals or the design approach is much
harder to live with. At some point one side has to give in or give up.
You say you've reached the point where you want to give up and take
your ideas elsewhere.
Seeing how much work and time you've poured into the project in the
past years, that would certainly cause a very difficult time for Trac.
The developer community around the project is IMHO not in a
particulary good shape, with the other "veterans" like Jonas and
myself devoting less and less time to the project, and relatively few
new people coming on board to fill the void. And developer
communication could probably not get any worse than it is right now.
Some of this is probably the result of a lack of a shared vision among
the team and the resulting friction. Some of it may be due to the
project growing beyond our ability to keep up. Etc.
There's a lot more to say on all this, but this mail is already long
enough, so I'll shut up for now.
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Mike
> we should go ahead and do that. These cases have been pretty rare so
> far though. The fact that you included wiki tags as a core feature
> illustrates this pretty well, I'm sure there are plenty of people on
> this list that don't care at all about tags.
>
>
> >> The problem I've had with Trac plugins so far is that there are a
> >> couple of interesting plugins that state their 0.10 version is broken
> >> (by design) and will not fixed until version 0.11, but version 0.11
>
> > I like this term - "broken by design" - that is a real pearl!
>
> The only plugin I know of that fits this is MasterTickets, and yes the
> design I picked for the 0.10 version turned out poorly. To say I
> purposefully picked a bad design is quite silly. I did a massive
> rework when I ported to 0.11 and it works much better. This is how
> development works, you try to improve things.
>
way.
Just the term itself is nice.
David Abrahams
on Fri May 30 2008, "Noah Kantrowitz" <noah-AT-coderanger.net> wrote:
> This would be a part of the long-fabled trac-hacks++ Alec and I have been
> discussing over the last year or so. I think this installer will solve the
> _real_ problem people are having. Its not that lots of plugins are a bad
> idea, they are just annoying to get working. Put this installer in Trac
> core, and you get the experience I think everyone wants.
I'm sorry, I have to disagree. Even as someone who's willing (when
necessary) to hack plugins and hack the Trac core to make them work
right in my environment, my problems with plugins are the same as some
others have mentioned in this thread. I need too many of them just to
get basic functionality and their compatibility with the latest Trac is
not always well-maintained.
Noah, are you hearing about different kinds of plugin problems from
other people, or are you saying something like that nobody who is
complaining really understands the problem they're having?
The economics of bringing a few mature, stable, and widely-needed
plugins into the official distribution are clear to me: when Trac makes
a code-breaking change, it's much easier to coordinate the code
transformations needed to keep all those plugins running. Often, I'm
sure, one person is doing a fairly mechanical scan through the Trac code
and can take care of everything in one shot.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
jevans
> > What about migration path and compatibility issues? There is no guarantee
> > on the future compatibility of MasterTickets and Trac.
> > Besides, MasterTickets looks quite limited. Trac is great, I bet you can
> > do better than that.
> >
> > I can't believe that Trac team avoided implementation of such essential
> > feature for so long (this ticket is 4+ years old). I love Trac but it's
> > unusable in large projects because of things like this. Sad.
>
> Nicely put, I can't agree more.
> Well, as you might have guessed by now, I've grown tired of this, and
> 0.11 will likely be my last Trac release, while I'm looking for ways to
> build an enhanced, more cohesive solution, in line with my ideas (this
> might succeed or not, but at least I won't have the feeling to bump into
> walls).
advocating for Trac at my workplace and I'm frustrated. I do however
hope you can stay on.
- jevans
Eirik Schwenke
Hash: SHA1
Caveat: I'm *not* a trac developer, I've barely scratched the surface of some
~ plugins
~ However, I do manage a few small-to-medium trac installs, recently
~ migrated from 0.10 to 0.11
My take on this is that:
a) keeping trac core simple is a good idea
b) having essential features in plugins is a good idea
~ 1) It implies anyone can add essential functionality that
~ they require without having to fork trac - because a solid
~ plugin api is available
~ 2) any such improvements should be relatively easy to reuse
These two points are just arguments for avoiding tight coupling, and
stimulating code reuse.
But what I think Trac need, is a proper framework for futureproofing plugins,
and make it easy for developers/maintainers to implement automatic updates.
I understand the pre 1.0 releases have an unstable api -- but a plugin upgrade
path will still be needed from 1.0 to 2.0 etc.
I'm not sure if pypi is the perfect model -- I think eggs work great, and some
kind of repository standard would be nice (preferably something simple along
the line of Debian's Aptitude -- all you'd need for hosting a mirror is a
webserver).
What I'd like to see is a model where new releases of trac (like 0.10 -> 0.11)
come with a migration script that also automatically wraps plugin updates
(provided a plugin has been ported to the new version).
Something along the lines of:
Upgrade trac:
1) shut down running instance
2) upgrade core
3) migrate wiki, database etc if necessary
4) for each plugin:
~ a) check metadata for a source/ search in a global repository
~ b) if an upgrade exist:
~ i) download
~ ii) run pre-install code that:
~ * upgrades datamodels, transforms wiki-references
~ * fixes workflows etc
~ * upgrades plugincode
~ c) if no upgrade exist - disable plugin
~ * note there should be stage 0) that checks all plugins for compatability
So, the main difference between this, and throwing all eggs under pypi-control,
and just running easy_install -U would be a defined framework/api for providing
migration-scripts integrated in the plugin-bundles, that does something
sensible with your legacy data/install if needed/possible -- and is able to
give a warning if what you're about to do will hopelessly break your install.
On a side note, it would be nice to have a simple robust way for setting up
local mirrors, hosting plugins etc -- again something along the lines of
aptitude (and probably pypi -- as I said I'm not quite sure how that stuff
really works).
I'd also like to see some an installer or something along those lines that
would allow one to do:
~ trac-install [--with-plugins=plugin1,plugin2(...)
~ [--use-local-files=/tmp/plugin1.egg ]]
And maybe even:
~ trac-install --with-suggested-plugins
If i understand you correctly Noah, this is similar to what you have in mind
(if we have a well-defined repository adding support for listing available,
compatible plugins in webadmin would probably be 3 lines of code, or so -- it's
not exactly rocket science).
So, again -- what I think we really need is some easy way for plugin devs to
implement automatic updates -- and a framework for automating such upgrades in
a "runnning" trac -- as well as an easy way to install trac with the plugins
one needs.
The only type of features I think should go into trac core, is the kind that
expands available metadata and apis in a reasonable way, that would be useful
to have work across many different plugins.
Webadmin is a perfect example of this -- all plugins will need to expose
various configuration settings via the web ui -- so having simple hooks for
that in trac makes sense.
Best regards,
- --
~ .---. 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
iD8DBQFIQvUtxUW7FIqjOSwRAkg/AKDTbXE2zd2vLC+DGFUDWPPt5Tq8JACfQF5O
ZBcQVhez4wYiKi5aPwf06G0=
=nYY1
-----END PGP SIGNATURE-----
Robert C Corsaro
> Christian, I couldn't agree more on what you wrote. That's exactly my
> point.
>
> Noah's wrote:
>> That kind of huge collection of features might
>> be good for boxing up and shipping to people that want a turnkey
>> solution, but they aren't much use in the Trac community
>
We have tried to put functionality into reusable components, but some
features are so small, they can't warrant there own plugin. It didn't
seem worth while to us to maintain a plugin that adds one simple filter.
Yet the code was still of value to the community as it was posted here
and someone used it. I think you bring up an important point though.
I'm just not sure what the solution is. Obviously posting code to the
list is not ideal.
Christian Boos
> Hey Christian,
>
Hello Chris,
Nice to see we had many points of convergence here, so I'll skip over
those and go straight to the parts that need a follow-up.
But before doing that, I would suggest that you could perhaps sum up the
position on which we mainly agreed, about the guidelines for what should
rather be done as a plugin and what should rather be contributed as a
patch to Trac proper. This would be an useful addition to the
TracDev/PluginDevelopment page for example, answering the "what"
question in addition to the "how", and you have more authority than I
have to speak on this topic.
> On 30.05.2008, at 11:00, Christian Boos wrote:
>
>> Now to answer the question "why has the Trac team avoided
>> implementation
>> of such essential feature (#31) for 4 years", it's quite simple: the
>> TracCrossReferences effort which was started (3 years ago) to address
>> that issue, among other things, didn't get any "traction", quite to
>> the
>> contrary, so it ended up in a branch which I stopped maintaining
>> after a
>> while.
>>
>
> You make it sound like the xref approach was the only way to get
> ticket dependencies into Trac. From my point of view, it was a very
> broad design ("among other things") bordering on over-engineering.
>
Well, it only explains why I didn't get any further. Also, the xref
branch should have focused on xrefs and relations should have been kept
separate, I guess.
>> People here at one hand are striving for "perfection", so any
>> incremental approach is considered very suspiciously,
>>
>
> I don't understand how striving for perfection conflicts with
> incremental development. Surely, a patchwork of incremental
> enhancements and fixes done without a common vision or design is not a
> good approach, and leads to an increasingly convoluted code base. I'm
> all for the evolutionary development of software, but it needs to be
> guided by design goals and quality standards in terms of API evolution.
>
We agree in principle. However with Trac, the problem space is kind of
big, and sometimes having a partial, less optimal solution, is better
than no solution at all. As for the design goals, I think I had them,
well exposed and documented, only they were not shared. As for the
quality standards in terms of API evolution, well, we can learn from the
mistakes of the past, can we? Some times ago, I even proposed a few
guidelines for 0.12 and beyond (see
http://groups.google.com/group/trac-dev/msg/4207c000d7c8be9c, more or
less what you're already doing for Genshi, adapted to the idea of
intermediate "reference points").
>> Well, as you might have guessed by now, I've grown tired of this, and
>> 0.11 will likely be my last Trac release, while I'm looking for ways
>> to
>> build an enhanced, more cohesive solution, in line with my ideas (this
>> might succeed or not, but at least I won't have the feeling to bump
>> into
>> walls).
>>
>
> I find this part somewhat misleading.
>
> By closing #31 and referencing this thread for dramatic effect or some
> kind of PR stunt, you make it look like the Trac team does not
> actually want to add ticket dependencies, but you do, so you want to
> fork. The thing is, there has AFAIK never been consensus that Trac
> should *not* have ticket dependencies in core. Noah suggested the
> ticket *could* be closed with reference to MasterTickets, but he
> didn't actually close it. You did.
>
In accordance with what I've said in an earlier discussion on Trac-dev
about this topic, a few months ago. Please read
http://groups.google.com/group/trac-dev/msg/eabd326df35d3eaa
But linking from #31 to this thread was indeed for dramatic effect, as I
think that the Trac project presents a high risk of becoming misguided
by the repeated "write a plugin!" stance, and IMO a kind of "wake up"
call was necessary.
> While I suppose there's some level of conflict between your preference
> to have more things in core, and the preference of some others to keep
> the core lean and simple, this is IMHO far overshadowed by the
> conflict over the long-term design (xref, GenericTrac, etc).
>
Well, it is somewhat related. If you have read my numerous e-mails and
wiki pages on the topic, you'd know that I've always defended the idea
that a /rationalization/ of Trac core would not only enable us to have
more features but also to have a much leaner and simpler code base,
instead of N different data models, N different ways of solving the same
problem over and over again. So yes, those are the real reasons where we
differ on the longer term vision.
> Any disagreements on core vs plugin can really be sorted out on a case-
> by-case basis,
>
The problem is not really plugin or not plugin, it's rather about the
foundation on which the plugins should be based. For example, should a
ticket relation feature introduce its own special purpose tables or
should that be based on some higher-level relationship feature? The same
when a plugin wants to introduce some new kind of resource, does it have
to start from scratch or be able to reuse a default storage mechanism
and some base functionalities? I'm even OK to have lots of nice little
plugins (preferably in a kind of standard plugin library), as long as
they don't each re-invent the wheel for base services (and admittedly,
we probably differ in what we see as base service - for me it's anything
related to linking between resources and the ability to trace changes).
> as long as we can all agree on the basic mantra that
> got Trac so popular in the first place. The following sentences have
> been on the homepage of the Trac project pretty much since day one:
>
> "Trac uses a minimalistic approach to web-based software project
> management. Our mission is to help developers write great software
> while staying out of the way. Trac should impose as little as possible
> on a team's established development process and policies."
>
The problem here is with the "minimalistic" approach. Does a
minimalistic approach really always "help developers to write great
software while staying out of the way"? Trac should indeed not impose
too much on a team's established development process and policies, but
it should help those teams to /improve/ their own process and policies.
As such, it has to offer efficient, rich and flexible ways to share and
work on the project-related information. And sometimes a minimalistic
approach can be at odds with this, if you have to fight your way in the
software instead of finding there the adequate support.
I must admit that I always thought that even if Trac's main strength was
in the integration of the base sub-systems (Wiki, BTS and VCS browser),
we should strive to make each of those sub-system a "best-of-breed" one.
Hence my tendency to expect the most of each of those sub-systems.
That's probably naive, sure, but well, this make things go forward ;-)
> That mantra does *not* mean Trac should not have ticket dependencies,
> or any other feature in particular. It just means that by default, we
> want to avoid ending up with a system that is too complex for people
> to use comfortably. And we certainly want to avoid imposing too much
> process on software projects.
>
Yes, exactly.
> A conflict in the long-term goals or the design approach is much
> harder to live with. At some point one side has to give in or give up.
> You say you've reached the point where you want to give up and take
> your ideas elsewhere.
>
> Seeing how much work and time you've poured into the project in the
> past years, that would certainly cause a very difficult time for Trac.
>
Well, I've not suddenly become "hostile" to Trac and even if we diverge
on some major design issues, that doesn't mean there aren't a lot of
areas where we can keep working together, even after a fork. A change of
name will probably make cross-project sharing of changes a bit more
inconvenient than a simple branching, but not by much. And whenever
possible, I intend to backport fixes (well, actually make them first in
Trac, then propagate those to the other project, in the same spirit we
now fix bugs first in 0.11-stable before porting them to trunk/0.12). So
in the end, I don't think my intention to do a "fast-forward" by taking
an alternate path will be detrimental to the project, and we could
eventually always merge later on, in parts or in whole, if that makes sense.
I need multiple project support, multiple relationships from tickets to
versions and milestones, and have milestones, versions and components as
first-class resources, etc. etc.
I need that /now/, not after some hypothetical 1.0 release, not after an
even more hypothetical time when we would reach an agreement on the design.
Wrong, I actually needed that 2 years ago. So I only hope I'll be able
to catch up the time lost.
> The developer community around the project is IMHO not in a
> particulary good shape, with the other "veterans" like Jonas and
> myself devoting less and less time to the project, and relatively few
> new people coming on board to fill the void. And developer
> communication could probably not get any worse than it is right now.
> Some of this is probably the result of a lack of a shared vision among
> the team and the resulting friction. Some of it may be due to the
> project growing beyond our ability to keep up. Etc.
>
Yes, I share that analysis, but I don't really see a way out,
unfortunately. I'll try to step out of the less technical discussions if
this can help, as I realize I'm not always the coolest tempered voice on
this mailing list.
-- Christian
Culapov Andrei
http://trac.edgewall.org/ticket/7293
On Thu, May 29, 2008 at 4:33 PM, Christian Boos <cb...@neuf.fr> wrote:
>
> Culapov Andrei wrote:
>> Hi Richard,
>> we implemented something exactly like this. Take a look
>> https://projects.optaros.com/trac/oforge/report/9
>>
>
> 401 :-)
>
> Other than that, the code looks interesting and even more so the OForge
> project.
> However, for this particular feature, I think it would have made more
> sense to write a patch against Trac, instead of writing a request filter
> + stream filter, as (to me at least) this issue looks more like a defect
> of the report subsystem rather than an optional feature: if you don't
> set the PRIORITY dynamic var, Trac reports an error page with no way to
> specify that value, which is not terribly useful. A simple list of input
> boxes for the missing variables would do, and plugins could still be
> implemented if anything more fancy is needed.
>
> -- Christian
>
> >
>
Christian Boos
Thanks, but I was already reading it ;-)
Looks quite good to me.
-- Christian
Erik Bray
<risto.k...@gmail.com> wrote:
>
>> > idea, they are just annoying to get working. Put this installer in Trac
>> > core, and you get the experience I think everyone wants.
>>
>> And it is called DLL, pardon, plugin hell ;-(
>
> Like with Firefox and its extenstions? I thought extensions have been
> its path to success: the core product cannot (and should not) please
> everyone and with extensions everyone can still make the product do
> what they need.
I actually generally prefer Opera simply because it gives me most of
the functionality I want out of the box (and from a still rather small
package) whereas every time I install Firefox I have to install at
least 5 extensions to get most of the same functionality. It's just a
shame Opera isn't open source :/
Trac, on the other hand, is server software over which I would want to
have fine control--it makes much more sense to keep the core package
lightweight, and only configure those plugins that I need for each
specific instance. You wouldn't want Apache to have all the most
commonly used modules built into it either--Apache's core is big
enough as it is. Frankly, it still surprises me how many people have
trouble configuring Trac, given that it's supposedly a tool for
developers. We're not talking about an office suite or something like
that here. I understand that even developers can't be bothered to
learn the inner workings of every tool they use, but I wouldn't say
it's necessary in Trac's case either. And I've rarely, if ever,
encountered Trac plugins that are incompatible with each other (at
least in cases where they theoretically shouldn't be incompatible).
I'm sure it exists, but it's rare. So that's hardly an excuse either.
Risto Kankkunen
> We use Trac at work to manage our monthly sprints, each sprint being a
> milestone. We have a number of reports to see how we are doing and
> they take the milestone as a parameter. For each milestone I make the
> milestone page contain links to the reports with the correct milestone
> parameter.
>
> Copy/pasting the previous milestone page and updating the parameters
> every month has become a bit boring, though. I wish I could somehow
> set the MILESTONE variable once in the page. Better yet, I wish I
> could include the page template giving the MILESTONE as an argument to
> the page!
>
> Anyone working on something like this?
parameters and with that I can make a common template for the
milestones and then in each milestone page just call the template with
a suitable parameter. Seems to work so far.
I guess this also tells something about Trac and its plugins: it took
me this long to realize that the feature I was looking for actually
existed as a plugin. And not just in one plugin, but three! There is
WikiInclude macro, then there is WikiIncludePlugin, which says
WikiInclude macro is broken and then there is TracWikiTemplates plugin
that tells WikiInclude macro is broken and that TracWikiTemplates
won't work with Trac 0.11. None of those has documentation comparable
to core Trac features. I chose WikiIncludePlugin and am now hoping
that stays functional so I don't have to switch to another plugin and
convert my template pages to another syntax in the future.
Having one well-documented and working "official" plugin would be
nice, but I don't know how to achieve that.