[SciPy-dev] Some Feedback

Mark Koudritsky kamrik at gmail.com
Sun Nov 13 07:00:13 CST 2005


Fernando Perez wrote:
> 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.

I agree that losing this integration would be a pity.
I'm not well familiar with Trac. Exactly how tight this integration is?

The ticket:NN feature can be easily duplicated in Moin using Moin's
"InterWiki links".
Moin has an editable dictionary of short tags and corresponding URLs.
A syntax like tag:PageName is translates to URL+PageName and converted
to a link.
For example WikiPedia:Kinase would point to wikipedia article on Kinase.
So we can simply define the tag "ticket" to point to the correct URL
in Trac so that URL+NN would open the ticket NN.
Same goes for milestones reports etc.

For the more sophisticated stuff, Moin has macros which are pretty
easy to write. I also played with extending the core syntax of Moin
it's also not that difficult.




On 11/13/05, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 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
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>




More information about the Scipy-dev mailing list