[SciPy-dev] Some Feedback
Fernando.Perez at colorado.edu
Sun Nov 13 03:24:37 CST 2005
Mark Koudritsky wrote:
> We don't have to see Trac+Moin as 2 separate systems, which, kind of,
> double each other. I would prefer to see it like this:
> Trac is a project management system with bug tracking system etc. But
> the built in wiki engine is not as mature and feature rich as Moin. So
> we can use Trac and use the Moin instead of Trac's native wiki engine
> (as a single composite system)
Well, does this mean losing the Trac wiki integration? One interesting
feature of Trac is that in any of its wiki pages, you can say for example:
and this automatically creates a proper Wiki link to Ticket #NN. The same
thing happens for milestones, reports, etc.
This is just to point out that the Trac wiki is very tightly integrated with
the specific development/subversion features of Trac. In Trac, the wiki is an
integral part of the system, which I find very nice. It may not be as flashy
as other wikis, but it stays out of the way and lets you get work done quickly.
Note that, due to the Trac design restriction of one SVN repo per Trac
for details), at the very least, we will have to deal with Trac-scipycore and
Trac-scpiyfull as two separate Trac instances.
This leaves us with:
- trac has a one svn repo/one trac instance model.
- trac by default ties logins to the svn developers with commit access. We
want non-developers with logins. Robert suggested a plugin which may take
care of this issue.
- We ABSOLUTELY must disable anonymous wiki edits. The ipython Trac is hardly
advertised anywhere (one link in the ipython main page, that's all) and today
Robert warned me of finding Wiki spam in it. Fortunately the problem was
caught after the scumbags had made a single new page, and I was able to simply
delete it right away. But I had to immediately disable anonymous edits, which
means that right now only those with ipython commit rights can make wiki
changes. The Enthought Trac was similarly defaced a few months ago, and I
don't think that one is advertised at all. These people WILL find any open
wiki and fill it with their junk.
- we may benefit from having a separate, more cleanly organized wiki for
user-facing support. This is where things like the TopicalSoftware pages,
cookbooks, documentation, etc. would live.
As a datapoint, I personally would like to have such a separation for ipython
as well, from the experience of using Trac over the last few months.
Here's one possibility that came to my mind: we could make a mock scpipy-web
SVN repo for this purpose only. This would allow the creation of a Trac
instance for the website, ASP project, documentation, etc, whose user accounts
would be separate from those of the developer repos. While still requiring
(if we block anonymous write access and the Trac login plugin doesn't work)
admin intervention for new user creation, at least there's a clear separation
between the users with write access here and the developers with write access
to the core/full repositories.
Now, it may well be that the Plone setup can be fixed to have more reasonable
performance and the full CMS power it brings may prove useful, I don't know.
But I'm finding Trac to be lightweight enough to be really easy to use, and
with the TracNav and TOC plugins to make it easy to add navigational aids to a
site, it doesn't have to produce the wiki-scatter websites which are so common
(I installed these two plugins for the ipython Trac today, they are trivial to
add and use).
As a way to test this, I am going to move the ipython main user site to
precisely such a Trac environment. Due to a permissions issue with Apache for
which I need help from root it didn't happen today, but I am going to give it
a try. I'll be happy to report back if I see any glaring problem with this
idea in actual use (though obviously ipython sees much less use than scipy, so
I may well miss something).
More information about the Scipy-dev