Developer mailing list for the Trac Project

Lance Hendrix | 3 Jun 2009 21:05

[Trac-dev] Re: Introduction & Looking to contribute

Thank you for the quick and elaborate response!  I wanted to follow up 
on this great email with a status of where I am and express my 
appreciation for your direction.  I have edited out a bit of this in 
order to shorten the email so that it isn't too long... 

My initial efforts have been to get a development environment up and 
running (I have done several user installations, but obviously never 
setup a "trac development environment).  I initially started out 
attempting to do this on Windows (Vista x64 to be exact), but ran into 
some issues and decided to switch over to Linux (Gentoo is my current 
preference with regard to distro), on which it was much easier to get 
going.  I still have quite a few failing tests in trunk and I am not 
sure if this is a result of issues with the environment (which I assume 
it is) or something else, but I will take the determination of these 
issues as part of my "training" in Trac development and figure them out 
on my own.

More comments are in-line:

Christian Boos wrote:
> Hello Lance,
>
>   
> Starting to work on the 0.11.x bug reports is where the contributions 
> will be the most immediately useful.
> I think 0.11.5 is mostly ready to go, though among the opened tickets, 
> there are still a few outstanding ones that would be better fixed in 
> 0.11.5 rather than later (e.g. #7490, #4245). In general, pick any 
> ticket in 0.11.5 or 0.11.6 that match your center of interest, and go

(Continue reading)

Christian Boos | 4 Jun 2009 17:35

Picon

[Trac-dev] Re: Introduction & Looking to contribute


I missed one detail in my previous answer:

Lance Hendrix wrote:
> ...
> My current thinking is that the explicit garbage collection (which is 
> synchronous with the user request) is what is causing the (at least 
> perceived) performance problem 

The explicit garbage collection happens after the response is sent, so 
the user visible delay shouldn't be impacted by this. The gc in itself 
is usually reasonably fast (typically less than 0.1s, but of course this 
varies with the system).

Now I wanted to verify that doing this gc.collect after each request 
really helped, so I did a few experiments with tracd (--http11), on 
Windows using ActivePython 2.5 and python.org Python 2.6:

0.11-stable unmodified (i.e. calling gc.collect after each request):
  Python 2.5 (svn 1.6.2)   26-27M
  Python 2.6 (no svn)      24-25M

0.11-stable modified (i.e. without calling gc.collect):
  Python 2.5 (svn 1.6.2)   34-37M
  Python 2.6 (no svn)      40-41M

(SQLite backend in both cases, Genshi advanced-i18n)

The numbers were obtained by repeatedly getting the Timeline page until 
the memory growth stabilized (it's never a fixed number, but stays

(Continue reading)

Christian Boos | 4 Jun 2009 12:22

Picon

[Trac-dev] Re: Introduction & Looking to contribute


Lance Hendrix wrote:
> Thank you for the quick and elaborate response!  I wanted to follow up 
> on this great email with a status of where I am and express my 
> appreciation for your direction.  I have edited out a bit of this in 
> order to shorten the email so that it isn't too long... 
>
> My initial efforts have been to get a development environment up and 
> running (I have done several user installations, but obviously never 
> setup a "trac development environment).  I initially started out 
> attempting to do this on Windows (Vista x64 to be exact), but ran into 
> some issues 

Well, Vista x64 is also my main development platform, although I mostly 
use the 32-bits version of Python those days (I didn't have any issues 
with the 64-bits version, it's just that you find less pre-built 64-bits 
Python packages on the net).

> Christian Boos wrote:
>   
>> Hello Lance,
>>
>>   
>> Starting to work on the 0.11.x bug reports is where the contributions 
>> will be the most immediately useful.
>> I think 0.11.5 is mostly ready to go, though among the opened tickets, 
>> there are still a few outstanding ones that would be better fixed in 
>> 0.11.5 rather than later (e.g. #7490, #4245). In general, pick any 
>> ticket in 0.11.5 or 0.11.6 that match your center of interest, and go 
>> for it: verify that an issue is reproducible, test an already proposed

(Continue reading)

Remy Blank | 3 Jun 2009 21:37

Picon

[Trac-dev] Re: Introduction & Looking to contribute

Lance Hendrix wrote:
> My initial efforts have been to get a development environment up and 
> running

...snip...

> I still have quite a few failing tests in trunk and I am not 
> sure if this is a result of issues with the environment (which I assume 
> it is) or something else,

Post the errors you get, I should be able to assist. I am also
developing on Gentoo, and have set up a few environments quite recently.
Are you using virtualenv? If not, you should.

-- Remy

Lance Hendrix | 3 Jun 2009 22:22

[Trac-dev] Re: Introduction & Looking to contribute


I get the same errors in virtualenv as I do when working in the 
"non-virtual" env (can I use Eclipse in a virtualenv)?  So I still 
assume it is a configuration problem in my environment (probably a RTFM 
issue or an ID10T issue ;-) ).  I am currently wondering if it is an 
issue with my PYTHONPATH (see first couple of lines of output of test 
session below) and that the tests can't find the "genshi" libraries(?).

My environment is as follows:

(trac-virt)lance <at> apollo ~/workspace/trac-virt/trac-trunk $ env
TERM=xterm
SHELL=/bin/bash
FORREST_HOME=/usr/local/src/apache-forrest
SSH_CLIENT=192.168.1.111 23595 22
QTDIR=/usr/qt/3
OLDPWD=/home/users/lance/workspace/trac-virt
SSH_TTY=/dev/pts/0
ANT_HOME=/usr/share/ant
USER=lance
GDK_USE_XFT=1
VIRTUAL_ENV=/home/lance/workspace/trac-virt
PAGER=/usr/bin/less
CONFIG_PROTECT_MASK=/etc/sandbox.d /etc/env.d/java/ 
/etc/php/cli-php5/ext-active/ /etc/php/cgi-php5/ext-active/ 
/etc/php/apache2-php5/ext-active/ /etc/udev/rules.d 
/etc/fonts/fonts.conf /etc/gconf /etc/terminfo /etc/ca-certificates.conf 
/etc/revdep-rebuild
XDG_CONFIG_DIRS=/etc/xdg
MAIL=/var/mail/lance

(Continue reading)

Remy Blank | 3 Jun 2009 23:05

Picon

[Trac-dev] Re: Introduction & Looking to contribute

Lance Hendrix wrote:
> I get the same errors in virtualenv as I do when working in the 
> "non-virtual" env (can I use Eclipse in a virtualenv)?  So I still 
> assume it is a configuration problem in my environment (probably a RTFM 
> issue or an ID10T issue  ).

It's not an RTFM issue, as there's currently no M to R about this 
Tim is right, you should install Genshi from the advanced-i18n branch.

For comparison, here's how I install a Trac development environment:

 - Install docutils, pygments, pytz, twill and lxml globally with emerge
(only once, obviously).

 - Check out a Trac working copy:

   $ svn co http://svn.edgewall.org/repos/trac/trunk
   $ cd trunk

 - Create a virtual environment within the checkout, and activate it:

   $ virtualenv venv
   $ . venv/bin/activate

 - Install Genshi into the virtual environment. I don't use a separate
checkout, as I (currently) don't intend to edit the Genshi code.

   $ easy_install -N
http://svn.edgewall.org/repos/genshi/branches/experimental/advanced-i18n

(Continue reading)

Christian Boos | 4 Jun 2009 10:48

Picon

[Trac-dev] Re: Introduction & Looking to contribute


Remy Blank wrote:
> Lance Hendrix wrote:
>   
>> I get the same errors in virtualenv as I do when working in the 
>> "non-virtual" env (can I use Eclipse in a virtualenv)?  So I still 
>> assume it is a configuration problem in my environment (probably a RTFM 
>> issue or an ID10T issue  ).
>>     
>
> It's not an RTFM issue, as there's currently no M to R about this 
> Tim is right, you should install Genshi from the advanced-i18n branch.
>   

Where should this information go? It's already mentioned in 
http://trac.edgewall.org/milestone/0.12 and 
http://trac.edgewall.org/wiki/TracL10N, but that's obviously not enough. 
What are the other places more likely to get consulted for such things? 
The trunk/INSTALL file?

> ...
>
> The message "unrecognized .svn/entries format; skipping ." when you run
> "python setup.py develop" seems to indicate that you are using
> Subversion 1.6.x. While we currently have no remaining incompatibilities
> with that version, setuptools does not support it yet, which may give
> some strange results (for example, the current revision is indicated as
> 0). If you can, I would suggest going back to 1.5.6 until setuptools
> catches up.
>

(Continue reading)

Lance Hendrix | 4 Jun 2009 20:53

[Trac-dev] Re: (renamed) Developer Documentation


Since there are several threads now under my original subject, I have 
renamed this one to Developer Documentation from "Introduction..."

I have taken the liberty of updating 
http://trac.edgewall.org/wiki/TracDev/DevelopmentEnvironmentSetup with 
the information you have provided below.  I am also giving some thought 
as to why I did not find these resources in the first place.  I think 
one idea I may have is to provide some additional content on the 
http://trac.edgewall.org/wiki/TracDev that explains the use of (value?) 
of each resource.  I would have (obviously incorrectly) assumed that the 
milestone page described milestone information such as requirements 
(what is being implemented) and functionality and did not think to 
consult this resource for installation/dependency requirements.  I think 
if some description/context for each of the links was provided on the 
page, it may have been easier for me to have found the information (at 
least in my still narrow view). 

Also, in reviewing the documentation, the Milestone 0.12 
(http://trac.edgewall.org/milestone/0.12) would seem to need to be 
updated (I don't have permissions to do this) as it describes Genshi 
0.5.1, while even 0.6 (and trunk) also do not work properly.  Although 
it does point you to the correct branch it does say "... or recent 
trunk", which (at least in my experience) is not correct (recent trunk 
does not seem to resolve the issue).

Lance

Christian Boos wrote:
> Remy Blank wrote:

(Continue reading)

velappan velappan | 5 Jun 2009 11:40

Picon

[Trac-dev] Re: (renamed) Developer Documentation


HI Lance,

I would to like to contribute for the trac team . Am using trac for
past one year.

Reagards
vela.velappan

On Jun 4, 11:53 pm, Lance Hendrix <la... <at> lancehendrix.com> wrote:
> Since there are several threads now under my original subject, I have
> renamed this one to Developer Documentation from "Introduction..."
>
> I have taken the liberty of updatinghttp://trac.edgewall.org/wiki/TracDev/DevelopmentEnvironmentSetupwith
> the information you have provided below.  I am also giving some thought
> as to why I did not find these resources in the first place.  I think
> one idea I may have is to provide some additional content on
thehttp://trac.edgewall.org/wiki/TracDevthat explains the use of (value?)
> of each resource.  I would have (obviously incorrectly) assumed that the
> milestone page described milestone information such as requirements
> (what is being implemented) and functionality and did not think to
> consult this resource for installation/dependency requirements.  I think
> if some description/context for each of the links was provided on the
> page, it may have been easier for me to have found the information (at
> least in my still narrow view).
>
> Also, in reviewing the documentation, the Milestone 0.12
> (http://trac.edgewall.org/milestone/0.12) would seem to need to be
> updated (I don't have permissions to do this) as it describes Genshi
> 0.5.1, while even 0.6 (and trunk) also do not work properly.  Although

(Continue reading)

Remy Blank | 4 Jun 2009 11:38

Picon

[Trac-dev] Re: Introduction & Looking to contribute

Christian Boos wrote:
> Where should this information go? It's already mentioned in 
> http://trac.edgewall.org/milestone/0.12 and 
> http://trac.edgewall.org/wiki/TracL10N, but that's obviously not enough. 
> What are the other places more likely to get consulted for such things? 
> The trunk/INSTALL file?

How about a big, fat warning on WikiStart? 

More seriously, is it possible to specify the Genshi dependency in
setup.py so that it downloads from the advanced-i18n branch?

I agree that the milestones are the right place to list such issues, but
it seems people (including myself) don't think of looking there. And
trunk/INSTALL, well, I don't remember ever reading it :-/

> Likewise, a link to http://bugs.python.org/setuptools/issue64 could be 
> added, maybe directly in setup.py?

How about a CurrentIssues (or maybe ThirdPartyIssues) page, listed on
WikiStart, that lists the most common obstacles for normal installation
/ development setup?

-- Remy

Lance Hendrix | 4 Jun 2009 18:08

[Trac-dev] Re: Introduction & Looking to contribute


Thank you for the pointers and for the additional sources to check for 
issues.  I had not thought to check the milestones, so I will ensure I 
read up on them.  I also didn't think to look at the L10N stuff, but 
will also review those.

As mentioned (and I personally abhor duplication whether code or 
documentation) if this information already lives somewhere, then IMHO 
pointers to this information should be provided rather than duplicating 
the information.

I will take the responsibility to update the .rst files with pointers 
and update where appropriate for the process (installation as well as 
pointers to resources for additional information) and provide it for 
everyones review and comment.  Should this information also be updated 
on the wiki?

I must admit I am a little confused with regards to the wiki and the 
*.rst files.  I followed the conversation yesterday in the (hijacked (my 
apologies)) thread on "Trac [Recipes]" and gathered that the consensus 
seems to be to continue to provide end user based documentation in 
(trac) wiki (this seems reasonable to me), but that developer 
documentation should be maintained in the *.rst files (also seems 
reasonable); however, what about the developer documentation that is 
currently on the wiki?  Should this be deprecated and only provide 
enough information to allow a developer to get access to the sources 
(location of svn repo and directions on which "set" of code to checkout) 
and then point them to the *.rst or should there be more info in the 
wiki?  What is the plan for use of the *.rst files, that is, will they 
be published or how will they be incorporated into the project?

(Continue reading)

Christian Boos | 4 Jun 2009 19:53

Picon

[Trac-dev] Re: Introduction & Looking to contribute


Lance Hendrix wrote:
> ...
> I must admit I am a little confused with regards to the wiki and the 
> *.rst files.  I followed the conversation yesterday in the (hijacked (my 
> apologies)) thread on "Trac [Recipes]" and gathered that the consensus 
> seems to be to continue to provide end user based documentation in 
> (trac) wiki (this seems reasonable to me), but that developer 
> documentation should be maintained in the *.rst files (also seems 
> reasonable); however, what about the developer documentation that is 
> currently on the wiki?  Should this be deprecated and only provide 
> enough information to allow a developer to get access to the sources 
> (location of svn repo and directions on which "set" of code to checkout) 
> and then point them to the *.rst or should there be more info in the 
> wiki?  What is the plan for use of the *.rst files, that is, will they 
> be published or how will they be incorporated into the project?
>
> Apologies for all the questions, but I also want to ensure that I don't 
> go in a direction that is contrary to where you guys are headed and I 
> don't have enough experience on the project IMHO to really understand 
> the nuances of these issues as yet, so I tend to ask more than a few 
> questions.  

No problem, the fact is that this is still in the making. When I was 
talking about using Sphinx for the developer guide, I was actually more 
thinking about the documentation for the API, where using such a tool is 
really necessary. Sphinx is quite superior to other similar tools, IMO, 
as you can better blend the API doc extracted from the source with 
contextual information and overviews (see the autodoc module [1]). Tim 
started to document the testing infrastructure in doc/dev, and I

(Continue reading)

Tim Hatch | 4 Jun 2009 17:28

[Trac-dev] Re: Introduction & Looking to contribute

Remy Blank wrote:
> Christian Boos wrote:
>> Where should this information go? It's already mentioned in 
> ...
> More seriously, is it possible to specify the Genshi dependency in
> setup.py so that it downloads from the advanced-i18n branch?

I was under the impression the advanced-i18n will someday be merged to
trunk, before we release 0.12.  I think it's at least appropriate to add
it to the "Understanding failures" section of doc/dev/testing.rst if
people hit this in tests.  Same for the following suggestion.

>> Likewise, a link to http://bugs.python.org/setuptools/issue64 could be 
>> added, maybe directly in setup.py?
> 
> How about a CurrentIssues (or maybe ThirdPartyIssues) page, listed on
> WikiStart, that lists the most common obstacles for normal installation
> / development setup?

Keep in mind we already have TracFaq and MostFrequentDuplicates.

Tim

Remy Blank | 4 Jun 2009 18:35

Picon

[Trac-dev] Re: Introduction & Looking to contribute

Tim Hatch wrote:
> I was under the impression the advanced-i18n will someday be merged to
> trunk, before we release 0.12.

That's what I understood, too. But in the current state of things,
somebody who installs Trac from trunk with easy_install will have the
wrong dependency pulled in. I was suggesting that we fix that now, if
possible, and revert the fix once advanced-i18n is merged to trunk.

> Keep in mind we already have TracFaq and MostFrequentDuplicates.

The FAQ is certainly a good source of information, although it has
become quite long. I was thinking more of a checklist of issues (often
in third-party components, hence the name ThirdPartyIssues) that we know
will affect many users, and should be solved within the next few
releases of these components, at which point we would remove the item
from the page. Some issues I would list:

 - If you install Trac from trunk, install Genshi from advanced-i18n.

 - Don't use Subversion 1.6.0 or 1.6.1 at all.

 - If you use Subversion 1.6.x and install from SVN, dependency
resolution will not work (setuptools issue).

But yeah, maybe we could just use MostFrequentDuplicates for that.

-- Remy

(Continue reading)

Lance Hendrix | 4 Jun 2009 00:07

[Trac-dev] Re: Introduction & Looking to contribute

Ah Ha!  One of the issues I have been having is that I generally have to 
edit the setup.py in Trac in order to get it to install as it wants a 
version of Genshi with a revision of something other than "0" (I have 
just been removing the -r*), which as you pointed out is an issue with 
SVN 1.6.  I can easily move back to 1.5 and will do so. 

I will also take your suggested process and re-do my environment as 
such.  While I am doing that, I will also update the *.rst files to 
reflect these changes (I had attempted to follow their direction, but 
now have some additional information that would probably be best 
added/revised in them).

Thanks!

Lance

Remy Blank wrote:
> Lance Hendrix wrote:
>   
>> I get the same errors in virtualenv as I do when working in the 
>> "non-virtual" env (can I use Eclipse in a virtualenv)?  So I still 
>> assume it is a configuration problem in my environment (probably a RTFM 
>> issue or an ID10T issue  ).
>>     
>
> It's not an RTFM issue, as there's currently no M to R about this 
> Tim is right, you should install Genshi from the advanced-i18n branch.
>
> For comparison, here's how I install a Trac development environment:

(Continue reading)

Tim Hatch | 3 Jun 2009 22:36

[Trac-dev] Re: Introduction & Looking to contribute

> TwillAssertionError:
> # No declaration for attribute xmlns:i18n of element html
> # URL: http://127.0.0.1:8743/newticket
> # Line 2, column 23
> 
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" 
> xmlns:i18n="http://genshi.edgewall.org/i18n">

This is probably related to Genshi #291, i18n stuff isn't being properly
stripped while rendering in Genshi trunk.  Best bet is switch Genshi to
advanced i18n:

http://svn.edgewall.org/repos/genshi/branches/experimental/advanced-i18n/

Let me know how that works for you...

Tim

[1] http://genshi.edgewall.org/ticket/291

Return

Return to gmane.comp.version-control.subversion.trac.devel.

Project Web Page

Developer mailing list for the Trac Project

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane