[SciPy-dev] Some Feedback

[Fernando Perez]

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:

ticket:NN

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 
instance (see 
http://projects.edgewall.com/trac/wiki/TracFaq#can-i-manage-multiple-projects-from-a-single-installation-of-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:

Facts:

- 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.


My opinion:

- 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).

Cheers,

f