Thoughts on Trac and Plugins and Newbies
Scott Bussinger
thought this would be the right time to put forward some thoughts on
how we might make it easier for other new users to take advantage of
Trac. I doubt anything I’m about to suggest is really new, but I
wanted to weigh in on the topic.
Getting Trac up and running the first time isn’t too hard, especially
with the changes made in 0.11. (As a side note, the documentation on
the wiki could be cleaned up a bit as there’s a lot of old information
hanging out in there. I’ll help with the Windows part of the install
docs.) But taking that next step from a basic working system to a
customized one taking full advantage of Trac is hard. Much of Trac's
strength comes from it's plugins. Trac's plugin system is very
flexible, but the documentation and project infrastructure make it a
fairly steep learning curve. In short, discovering and installing
plugins is hard for beginners. Handling updates with lots of plugins
is also tough (especially with Trac's historically long update
cycles).
The current Trac development philosophy seems to be to keep the core
lean and provide lots of extension points. I think that’s a great
philosophy and fully agree with it. My thoughts are not about changing
the implementation of Trac, but changing the nomenclature around Trac.
If the developers make everything practical a plugin and only add
changes to the core that support key features needed/desired by plugin
authors, that satisfies both the flexibility and leanness objectives.
My suggestion is to introduce three artificial levels of plugins. By
“artificial” I simply mean that there’s no implementation difference
between the levels, this is just about how they are delivered and
documented. Those levels would be
Core Features
Trac Options
Trac Plugins
“Core Features” would be included in the base Trac installation and
enabled by default. Examples would be the Trac wiki, admin pages,
search, and other such basic building blocks of a Trac installation. A
nice admin page for disabling core features where appropriate would be
great (if you wanted to disable the report module for instance).
“Trac Options” would also be included in the base Trac installation
but disabled by default. Again, a nice admin page for enabling these
optional features would be great. These option plugins would be those
particularly useful/powerful plugins that the development team deems
stable enough and appropriate. The key here is that these option
plugins would be maintained as part of the Trac release process. The
whole point here is to keep the core lean and not weigh the core down
with unnecessary plugins being loaded, but ensure that if you enable
one of these optional features it will continue to work if you upgrade
Trac to a new release. Examples of these would be the existing sample
plugins like Timestamp as well as extremely popular plugins like
AccountManagerPlugin.
“Trac Plugins” would be all the other stuff from trac-hacks.org and
would be handled pretty much as it is now -- a free-for-all that can
include anything, but it’s up to the user to ensure that a plugin is
compatible with a new Trac release.
This would make it easier for people to gain access to features that
are very commonly used but don’t need to be part of the Trac core. It
would also simplify the upgrading process to new Trac releases (since
you’d know that optional pieces you depend on are already compatible).
The space requirements are trivial (it’s not like plugins are very
big). Since the Core Features and Trac Options are constrained lists
known in advance, we could have special admin pages that simplify
enabling/disabling these plugins to customize a Trac installation.
This could really help out new users. Voting on the mailing lists
could handle moving a plugin into the Trac Option category.
I'd like to see a fairly large number of the commonly used plugins
moved into the Trac Option category. In some cases there should
probably be a bit of refactoring of the existing plugins to follow a
more cohesive plan, but that can be worked out as we go.
I hope I didn’t step on any toes here, but I do think this would help
people take advantage of Trac.
Noah Kantrowitz
This shares the same issues as the current system. People will still
want their favorite feature made into an "option" instead of a plugin,
and bundling things removes most of the benefits of using plugins.
There is a very simple way to fix this, we need to remove the
distinction between "Trac" and "plugins". Trac is just a collection of
plugins you install, and it needs to be easy to install more. Quality
control is an issue, but it will always be an issue. Community ratings
will help that though. Having more divisions will cause problems not
fix them.
--Noah
osimons
that plugins is pretty much a requirement for any non-trivial test
setup. However, as Noah says, exactly what plugins one needs will
depend, and it is exceedingly difficult to make something that suits
all - especially handled and coordinated by the Trac developers that
also have a ton of other current and future fixes and enhancements to
focus on.
What I would like to see would be that people with similar needs came
together to maintain 'community' versions of their Trac setup with a
set of plugins they would need for their use. Using svn:externals it
could pull in Trac source and plugins and other third party modules as
it needs (pegged at certain tested revisions for instance), and the
only additional code would be a tried & tested script to install and
upgrade everything correctly + perhaps some minimal scaffolding to
make it all come together; virtualenv setup, fixed folder structure,
fcgi/wsgi scripts working out of the box and similar.
A community version for consultant shops, a version for internal
software development, a version for community projects and so on.
Bundle in a custom theme, recommended workflows, reports, permission
setup and the like. It would work best by being based on what some
organisations ause daily, and are prepared to invite others in to help
use, test and maintain.
That would a) make it easier to install, deploy and maintain, and b)
make sure that different Trac and plugin combinations got tested and
maintained, and c) offered a secondary support path for users for
issues that are strictly not related to Trac development itself.
I am not a great believer in the design-by-committee, and the
everything-delivered-and-supported-by-Trac based on popular vote is
guaranteed to be a frustrating experience for everyone involved.
:::simon
https://www.coderesort.com
Scott Bussinger
> together to maintain 'community' versions of their Trac setup with a
> set of plugins they would need for their use.
Fragmentation (and yes, they're related).
If you break Trac up into a number of sub-projects for each community,
you're more likely to dilute the public awareness of what Trac is. I
think the OForge project is exactly the type of thing you're talking
about (http://code.optaros.com/trac/oforge/). While I applaud the
efforts put into OForge, nobody who's not already familiar with Trac
and OForge are going to have any idea that "OForge" and "Trac" are
indeed intimately related. In fact the only place on the OForge
homepage that mentions Trac is the "Trac Powered" logo in the footer.
So if OForge becomes popular (and develops it's own "brand"), Trac
isn't really going to benefit much from that. Similarly the improving
popularity of Trac isn't really going to help OForge become more
popular. It's not clear to me how having 3 or 4 separate sub-projects
helps Trac.
By Fragmentation, I mean that it'll be easy for efforts put into a the
sub-projects to not be generally promoting Trac as a whole. If
everyone's careful this can be mitigated, but it's a slippery slope as
well. It's easy to get in a situation where a sub-project needs a
slightly variation on a plugin. It's not generally useful outside of
the sub-project environment so they fork it off. Now future changes to
the original plugin and the forked plugin need to be maintained
separately. Over time this is tough.
> I am not a great believer in the design-by-committee, and the
> everything-delivered-and-supported-by-Trac based on popular vote is
> guaranteed to be a frustrating experience for everyone involved.
lots-of-separate-committees" can be a problem as well. As for "popular
vote", I was thinking more along the lines of "core developer vote". I
wasn't suggesting that the entire community as a whole make final
design decisions as to what should be included as a "Core Feature".
What I do think would be useful is having the people using Trac
expressing their thoughts/needs (like the new ticket voting on T.E.O),
and the people doing the actual work on Trac taking that into account
as they make their decisions. But the final call should be with the
people who understand Trac the best (the core developers).
Noah Kantrowitz
On Jun 29, 2008, at 1:53 PM, Scott Bussinger wrote:
>
>> What I would like to see would be that people with similar needs came
>> together to maintain 'community' versions of their Trac setup with a
>> set of plugins they would need for their use.
>
> I have two concerns with that approach -- Brand Dilution and
> Fragmentation (and yes, they're related).
>
> If you break Trac up into a number of sub-projects for each community,
> you're more likely to dilute the public awareness of what Trac is. I
> think the OForge project is exactly the type of thing you're talking
> about (http://code.optaros.com/trac/oforge/). While I applaud the
> efforts put into OForge, nobody who's not already familiar with Trac
> and OForge are going to have any idea that "OForge" and "Trac" are
> indeed intimately related. In fact the only place on the OForge
> homepage that mentions Trac is the "Trac Powered" logo in the footer.
> So if OForge becomes popular (and develops it's own "brand"), Trac
> isn't really going to benefit much from that. Similarly the improving
> popularity of Trac isn't really going to help OForge become more
> popular. It's not clear to me how having 3 or 4 separate sub-projects
> helps Trac.
>
Why is this a problem. We develop Trac to provide people with the
tools, it really doesn't matter if they don't know what Trac is. Brand
identity issues matter much less in a FOSS world, where money isn't a
concern.
> By Fragmentation, I mean that it'll be easy for efforts put into a the
> sub-projects to not be generally promoting Trac as a whole. If
> everyone's careful this can be mitigated, but it's a slippery slope as
> well. It's easy to get in a situation where a sub-project needs a
> slightly variation on a plugin. It's not generally useful outside of
> the sub-project environment so they fork it off. Now future changes to
> the original plugin and the forked plugin need to be maintained
> separately. Over time this is tough.
Proper design can help mitigate this, but if people are determined to
make single-purpose hacky solutions nothing will stop them. These are
the same people that would rather maintain a local patch to Trac than
make a plugin.
>
>> I am not a great believer in the design-by-committee, and the
>> everything-delivered-and-supported-by-Trac based on popular vote is
>> guaranteed to be a frustrating experience for everyone involved.
>
> I agree that "design-by-committee" can be a problem. But "design-by-
> lots-of-separate-committees" can be a problem as well. As for "popular
> vote", I was thinking more along the lines of "core developer vote". I
> wasn't suggesting that the entire community as a whole make final
> design decisions as to what should be included as a "Core Feature".
> What I do think would be useful is having the people using Trac
> expressing their thoughts/needs (like the new ticket voting on T.E.O),
> and the people doing the actual work on Trac taking that into account
> as they make their decisions. But the final call should be with the
> people who understand Trac the best (the core developers).
Of course, the votes on t.e.o are just to guide us. It is being called
into question as to if we actually know what users want, so the vote
numbers give at least some idea. There is a huge non-response bias of
course, so the numbers must be taken with a grain (or 12) of salt.
--Noah
Scott Bussinger
> want their favorite feature made into an "option" instead of a plugin,
> and bundling things removes most of the benefits of using plugins.
draw a line between plugins that offer generally useful functionality
(Trac Option) versus those that are a rather specific (Trac Plugin).
For instance, a WYSIWYG plugin is generally useful. The GraphViz
plugin is pretty specific. The BackLinks macro is generally useful, an
IRC plugin is pretty specific. To pick a more potentially
controversial example, a plugin that adds some simple time accounting
fields might be generally useful, a plugin that turns that information
into a scrum burndown chart would be pretty specific.
> Trac is just a collection of plugins you install, and
> it needs to be easy to install more.
the process of loading third party plugins would be great. My
suggestion revolves around making it as easy as you possibly can to
load some of the most common and most useful plugins (i.e. by pre-
installing them even though you wouldn't pre-enable them).
> Quality control is an issue, but it will always be an issue.
critical) plugins will work when Trac is upgraded is important as
well. Perhaps the number of API changes in recent releases of Trac is
atypical, but the number of plugins designed for Trac 0.9 that still
work without change in 0.11 seem rather limited. Look at the comments
in the newsgroups from people who are still running old versions of
Trac (like 0.9-era). For them to update to the new 0.11 release is
likely to be a non-trivial exercise.
> Having more divisions will cause problems not fix them.
Look at trac-hacks.org for instance. There are sections for
"Integrating Trac with 3rd party Applications", "Macros", "Patches",
"Plugins", "Scripts", "Themes", "Translations", "Tutorials", and
"Ticket Workflows". Some of those distinctions are real in the sense
that are used in very different ways (e.g. the scripts are generally
utilities used outside of Trac itself, whereas patches are special
modifications to the Trac source code). Others are artificial
distinctions, such as macros and plugins. Macros are just plugins with
a particular purpose in mind (tweaking the Wiki engine). The same for
Themes.
Those divisions are useful distinctions that make it easier to find
what you need. And that makes it more likely that a new user will take
advantage of them. The intent behind my proposal is the same -- to
make it easier for new users to take advantage of Trac. Note that I
don't want to get in the way of the experienced users, but I don't
think this proposal would.
Scott Bussinger
> tools, it really doesn't matter if they don't know what Trac is. Brand
> identity issues matter much less in a FOSS world, where money isn't a
> concern.
Trac as a solution. As the old adage says, "Time is money". Whether
something takes a lot of time or it takes a lot of money, it's
expensive. If Trac were to fail and stop being developed, I'd have to
move to an alternate solution and that would entail many more hours of
time spent. Let me use myself as a specific example. We originally
started using a version control system called TLIB (around 1989).
Later we switched to CVS because we needed more modern features. Most
recently we moved to Subversion. We converted all of the revision
history from one system to the next. Making those moves was expensive
even though both CVS and Subversion were FOSS.
I also used to use CVSTrac for many years and switched recently to
Trac because it was more powerful and more actively developed. Again
we converted all of our old CVSTrac data to Trac. That move was also
"expensive".
There are lots of examples of FOSS where they've made branding
important. Take Apache and Mozilla for instance. I'd argue that their
efforts towards branding have significantly improved their projects.
The best project ever invented is of no consequence if nobody knows it
exists. If nobody cares, nobody's going to work with it and it will
eventually die. "Branding" may have some negative marketing
connotations, but the concept of identity and awareness is very real.
> Of course, the votes on t.e.o are just to guide us. It is being called
> into question as to if we actually know what users want, so the vote
> numbers give at least some idea. There is a huge non-response bias of
> course, so the numbers must be taken with a grain (or 12) of salt.
vote, there's also a bias because it's not particularly obvious how to
enable voting. It wasn't until I searched the newsgroups again that I
found out the trick to enabling the voting buttons (you have to go to
the preferences page and create a cookie before you can vote).
Another problem with the voting is that the tickets weren't originally
created with the intent of clear purpose for voting in mind. If you
look at the first four entries on the report right now, it's not
really clear to me what the distinctions are between "Add support for
Master tickets" and "Bug dependencies/relations" is. At first blush it
seems like they might boil down to the same thing. But that doesn't
mean you could combine their votes into a single weight because people
might have voted for both.
I'm similarly confused about "Multi-project support" and "better
support for multiple repositories". I'm not saying they're the same
thing, but it's not clear to me what common ground they may or may not
have.
Noah Kantrowitz
On Jun 29, 2008, at 3:45 PM, Scott Bussinger wrote:
>
>> Why is this a problem. We develop Trac to provide people with the
>> tools, it really doesn't matter if they don't know what Trac is.
>> Brand
>> identity issues matter much less in a FOSS world, where money isn't a
>> concern.
>
> Absolutely it's a concern. I have many, many hours invested into using
> Trac as a solution. As the old adage says, "Time is money". Whether
> something takes a lot of time or it takes a lot of money, it's
> expensive. If Trac were to fail and stop being developed, I'd have to
> move to an alternate solution and that would entail many more hours of
> time spent. Let me use myself as a specific example. We originally
> started using a version control system called TLIB (around 1989).
> Later we switched to CVS because we needed more modern features. Most
> recently we moved to Subversion. We converted all of the revision
> history from one system to the next. Making those moves was expensive
> even though both CVS and Subversion were FOSS.
You misunderstand. I, as a Trac developer, do not care if the end user
sees something branded "Trac" or something branded "Super-Mega-
Enterprise Project Awesomeness X9". I will just keep working on Trac
as I always do. If the rebranded project gets the tools I make into
the hands of developers, my mission has been accomplished. If you are
looking for glory and fame, FOSS really is not the right place to do it.
--Noah
Scott Bussinger
> not the right place to do it.
working on FOSS when it comes to future jobs or contracts. But mostly
it's just a work of "love". My wholehearted thanks go out to you and
the rest of the Trac team for the efforts you put into it. I
contributed a lot of time to the programming community in the old days
(pre-internet), but drifted away from it as life got hectic. One of my
personal goals is to actively head back the other direction again. I'd
like to contribute to the Trac project in the future, but the
development stack (python with a bit of emphasis on linux/apache) is
not an area where I do any other programming so my skills aren't much
help here. I am thinking I can help with documentation a bit though.
> gets the tools I make into the hands of
> developers, my mission has been accomplished.
more gratifying to have your efforts in the hands of a hundred
thousand developers than in the hands of a hundred developers? Browse
around on SourceForge and you'll find lots of interesting projects
that are dying for lack of an audience. Lack of audience means fewer
developers willing to spend time on the project. Fewer developers
means a project that's more likely to wilt away.
The most successful projects make an effort to brand their "product".
Witness things like www.spreadfirefox.com with their affiliate buttons
and "Download Day" promotions. I'm not saying Trac should do that kind
of marketing, but I don't think it will help Trac to dilute down the
presence and awareness they've already earned.
Noah Kantrowitz
>
>> I, as a Trac developer, do not care if the end user sees something
>> branded "Trac" or something branded "Super-Mega-Enterprise Project
>> Awesomeness X9". I will just keep working on Trac as I always do.
>
>> If you are looking for glory and fame, FOSS really is
>> not the right place to do it.
>
> Agreed. There can be some positive benefits to individuals from
> working on FOSS when it comes to future jobs or contracts. But mostly
> it's just a work of "love". My wholehearted thanks go out to you and
> the rest of the Trac team for the efforts you put into it. I
> contributed a lot of time to the programming community in the old days
> (pre-internet), but drifted away from it as life got hectic. One of my
> personal goals is to actively head back the other direction again. I'd
> like to contribute to the Trac project in the future, but the
> development stack (python with a bit of emphasis on linux/apache) is
> not an area where I do any other programming so my skills aren't much
> help here. I am thinking I can help with documentation a bit though.
Not sure where you got that idea, we place no emphasis on any
particular platform.
>
>> gets the tools I make into the hands of
>> developers, my mission has been accomplished.
>
> I have no idea what the Trac download stats are, but wouldn't it be
> more gratifying to have your efforts in the hands of a hundred
> thousand developers than in the hands of a hundred developers? Browse
> around on SourceForge and you'll find lots of interesting projects
> that are dying for lack of an audience. Lack of audience means fewer
> developers willing to spend time on the project. Fewer developers
> means a project that's more likely to wilt away.
No, not really. I like what I do, and I know it is good work. I don't
need big numbers to justify it to myself. Any developer that doesn't
work on a FOSS project because it has a small userbase isn't cut out
for the FOSS world IMO. I don't disagree that it takes a certain kind
of developer to survive the wiles of open source, but I don't think
this can or should be changed.
--Noah
Scott Bussinger
> particular platform.
feel to me like there are more people using Trac under Linux than
under Windows. And the options for hosting are either standalone or
Apache.
It's generally not a problem, but virtually all the command line
examples on the wiki (that aren't on Windows-specific pages) are for
Linux shells. The Scripts section on trac-hacks.org are far more
likely to be Linux shell scripts than Windows batch files. If there's
a discussion about Trac and scheduling, the discussion generally
revolves around CRON. And so on. It's better than on many FOSS
projects.
I've run into a few things where I had to figure out the Windows
equivalent to a Linux-ism, but as I said it's generally not been a
problem. I do tend to avoid things like spaces in filenames and keep
filenames lowercase only to avoid problems though.
The statement was really intended as a comment about my limitations,
not Trac. I can generally keep out of trouble on a Linux system, but I
have no where near the comfort level I have with a Microsoft OS.
Noah Kantrowitz
>
>> Not sure where you got that idea, we place no emphasis on any
>> particular platform.
>
> Well, I did say just "a bit of emphasis". It's not a lot, but it does
> feel to me like there are more people using Trac under Linux than
> under Windows. And the options for hosting are either standalone or
> Apache.
AFAIK we have at least one core developer running Windows almost
exclusively. t.e.o runs LigHTTPD, as do many popular sites. Other
known deployment options include nginx, twisted.web2, CherryPy,
paste.httpserver, litespeed. There are probably even more, but I tend
to lose count. While we obviously cannot force 3rd-party contributions
to be platform-neutral, it is generally encouraged where possible. I
will grant you that we generally say "cron" when we mean "generic time-
based daemon", but then even a few popular linuxes no longer use cron
itself for that ;-) I agree there is a sentiment that Trac is Linux
software, and I would certainly like to reverse that whereever
possible. Once interesting idea I saw on a ticket a while ago would be
trying to get Trac running on IronPython or Jython. Porting Genshi is
probably the hardest part of that, but it would allow us to tie in to
many Windows shops' existing .NET or J2EE stack. Improving our Windows
docs (at least bringing them up to the level of the other ones) would
also probably help. Any volunteers? :-)
--Noah
Jani Tiainen
> On Jun 29, 2008, at 8:43 PM, Scott Bussinger wrote:
>
>>> Not sure where you got that idea, we place no emphasis on any
>>> particular platform.
>> Well, I did say just "a bit of emphasis". It's not a lot, but it does
>> feel to me like there are more people using Trac under Linux than
>> under Windows. And the options for hosting are either standalone or
>> Apache.
>
> AFAIK we have at least one core developer running Windows almost
> exclusively.
I've been runnin Trac production on windows (from versions 0.8.4 to
0.9.x) then for various reasons I switched over Linux.
All Trac development, tests etc. I've always done in Windows. Lately I
managed to get Eclipse + pydev to work with Trac and that makes
development very convenient.
> t.e.o runs LigHTTPD, as do many popular sites. Other
> known deployment options include nginx, twisted.web2, CherryPy,
> paste.httpserver, litespeed.
> There are probably even more, but I tend
> to lose count.
Evil itself: IIS :D
> While we obviously cannot force 3rd-party contributions
> to be platform-neutral, it is generally encouraged where possible.
There is only few plugins that have some native dependencies that are
hard to get working on non-posix platform.
> I
> will grant you that we generally say "cron" when we mean "generic time-
> based daemon", but then even a few popular linuxes no longer use cron
> itself for that ;-) I agree there is a sentiment that Trac is Linux
> software, and I would certainly like to reverse that whereever
> possible.
> Once interesting idea I saw on a ticket a while ago would be
> trying to get Trac running on IronPython or Jython.
IronPython would be most interesting one... :D
> Porting Genshi is
> probably the hardest part of that, but it would allow us to tie in to
> many Windows shops' existing .NET or J2EE stack.
I think hardest part might be getting all non-python code to work.
Specially database drivers and svn bindings...
> Improving our Windows
> docs (at least bringing them up to the level of the other ones) would
> also probably help. Any volunteers? :-)
Not yet... Even I should help in that one. It's easy to say that docs
sucks but I don't want to help :D
But as spoken in other thread 'first time user experience' is not a warm
welcome. There is too many steps, too many options that you need to
choose from _before_ you're familiar with Trac. It's really hard to
determine is Trac "cheap" or "expensive" or even suitable.
Which brings me now idea to run a questionaire about these FTUE issues.
Wonder what would be best way to run questionaire where would be asked
about os/httpd/plugins and how people experienced installation and tryouts.
--
Jani Tiainen
Simon Martin
On Jun 27, 9:12 pm, osimons <oddsim...@gmail.com> wrote:
> First, I have to agree with the sentiment that Trac needs plugins and
> that plugins is pretty much a requirement for any non-trivial test
> setup. However, as Noah says, exactly what plugins one needs will
> depend, and it is exceedingly difficult to make something that suits
> all - especially handled and coordinated by the Trac developers that
> also have a ton of other current and future fixes and enhancements to
> focus on.
>
> What I would like to see would be that people with similar needs came
> together to maintain 'community' versions of their Trac setup with a
> set of plugins they would need for their use. Using svn:externals it
> could pull in Trac source and plugins and other third party modules as
> it needs (pegged at certain tested revisions for instance), and the
> only additional code would be a tried & tested script to install and
> upgrade everything correctly + perhaps some minimal scaffolding to
> make it all come together; virtualenv setup, fixed folder structure,
> fcgi/wsgi scripts working out of the box and similar.
everyone's needs. But I'm sure there is a set of plugins which most of
the users need (AccoutManager!). And even if some users just need two
of four shipped plugins, they would highly appreciate it, if this
would be just a one-click installation. Again, just the installation
of the plugins isn't the big deal, but finding the correct revision of
a specific plugin for your updated trac installation really is a big
deal.
What's the magic set of plugins most users need has to be evaluated by
some metrics (no. of downloads, votes on teo etc) and discussed. And I
don't think you can decide this once for all times, but again and
again.
I agree with Scott, "community versions" won't solve this issue. More
likely you probably will miss the "break-even" number of users and
developers for all or most community versions and many of them will
die due to lack of audience.
BR,
Simon
David Abrahams
on Fri Jun 27 2008, Noah Kantrowitz <noah-AT-coderanger.net> wrote:
> This shares the same issues as the current system. People will still
> want their favorite feature made into an "option" instead of a plugin,
> and bundling things removes most of the benefits of using plugins.
> There is a very simple way to fix this, we need to remove the
> distinction between "Trac" and "plugins". Trac is just a collection of
> plugins you install, and it needs to be easy to install more. Quality
> control is an issue, but it will always be an issue. Community ratings
> will help that though. Having more divisions will cause problems not
> fix them.
One of the simple ease-of-use upgrades I've had in Trac for a long time
is the functionality proposed in http://trac.edgewall.org/ticket/5340.
This was (at one point anyway) a one-or-two-line change that made the
Trac user experience substantially better for most auth methods one
might choose. In fact, without it, I have had numerous smart,
experienced tech people become confused (and some of them angry!) when
they see Trac's permissions errors instead of a login screen. IMO, the
empirical user feedback speaks for itself. I can't blame them, either.
Show me one other popular web software package that generates such a
loud permissions error while hiding the "fix" away in a little link that
is not very prominent when the error occurs.
The suggestion in the ticket was to use
http://trac-hacks.org/wiki/PermRedirectPlugin. Problems with that:
0. The total amount of code required to package this as a plugin
compared to what it would take to integrate it into Trac doesn't
make economic sense from a maintenance point-of-view. But in
theory that's not my problem.
1. Other Trac administrators have to discover this plugin in order to
get up to what many people consider a minimally acceptable level of
usability.
2. The plugin isn't working with 0.11; at least not for us.
This plugin, as it is developed by Noah, by rights ought to stand a
better chance than many others of maintaining compatibility with the
Trac release. I don't think this would have happened if the
functionality was in the Trac core. In fact, I'm pretty sure that #2
above is at least partly related to #0.
I'm not trying to say that lots of plugins ought to be pulled into the
core. I share the OP's point of view that the separation and modularity
is beneficial.
The current approach appears to be "if it can go in the core, it
should"... sometimes. For example, it's my impression that there's a
lot of wiki formatting functionality in the core that could be in a
plugin. I think, at the very least, the criteria for deciding what
belongs in the core ought to be revisited, nailed down, made consistent,
and then publicized. If the policy were clear, consistent, and known, I
bet you'd stop seeing clones of this thread pop up every few weeks.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Simon Martin
On Jul 15, 2:51 pm, David Abrahams <d...@boostpro.com> wrote:
[snip]
> 2. The plugin isn't working with 0.11; at least not for us.
>
this is a "feature" Trac should provide out-of-the-box. Just added it
to http://trac.edgewall.org/wiki/SeaChange/WhatUsersWant
BR,
Simon
David Abrahams
on Tue Jul 15 2008, David Abrahams <dave-AT-boostpro.com> wrote:
> The current approach appears to be "if it can go in the core, it
> should"... sometimes.
Err, I meant
"if it can go in a plugin, it should"...sometimes
Sorry for the confusion. :(
Jeroen Ruigrok van der Werven
>but the development stack (python with a bit of emphasis on linux/apache)
Given I use FreeBSD and lighttpd I resent that remark. :)
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Who watches the watchers?