[Pydotorg-www] [Pydotorg] quick break down of trac tickets

Stephan Deibel sdeibel at wingware.com
Thu Oct 19 03:53:43 CEST 2006


[Only replying to pydotorg-www since pydotorg mailing list 
traffic should avoid things specific to the website build or 
content, except when sys admin intervention is needed]

On Wed, 18 Oct 2006, Michael Steinfeld wrote:
> I know most everybody has more important things to do then worry  
> about trivial problems on the website, but before I can really help  
> out I need to understand some things.
> 
> first of all, a lot of the trac tickets are old but not closed. Do I  
> assume that they are all in need of being completed or that they are  
> actually taken care of but nobody closed them?

All open tickets are tickets that nobody has looked at or have 
not been completed.   I've occassionally found tickets 
someone took care of by chance while doing something 
related, but this is fairly rare.

Whether we want all these tickets to be done is another story -- 
some we should just reject, but for now err on the side of 
leaving them open until you've gotten more experience with the 
website and contextual knowledge for making these decisions.

> Also, I had a ticket where someone wanted us to post a link-claiming  
> they had a lot of python jobs-to their job board, which was a  
> marketing company. I searched for 'python jobs' and nothing came  
> back. I closed the ticket and explained my reasons. I guess I should  
> just use common sense in this regard?

Yes.  If someone requests a link that makes no sense, it's pretty 
clear we should reject the request.  Feel free to apply common 
sense and for that kind of thing you don't need to worry about 
acquiring more knowledge about the website first! :-)

As an aside, policy for the mirrors list is that we add mirrors 
only if they are unaltered exact copies of the website.  Some 
people add a header/footer or alter content, usually with the 
intent of spamming Google.  Oh, and by the way, mirrors are 
listed in mirrors.db and processed down as part of the build 
process.  Don't edit the mirrors/content.rst file directly.

> I don't want to close tickets that I have no idea if they still stand  
> or not. I guess I am pretty anal, but I hate seeing open tickets. I  
> would like some suggestions on how I should go about cleaning them up  
> and finding out of the issue has/hasn't been solved.

When in doubt, post a comment or ask your question in the ticket 
and I and others will see that and can respond.  Or just post to 
pydotorg-www.  I tend to prefer doing it under the ticket but 
lengthy discussions in that context tend not be be fruitful.

> It also would be helpful if I had some knowledge on how a page is  
> generated. It would save me some time not having to figure this all  
> out on my own.
>
> more or less a quick run down of the basic layout of pydotorg.

It's black magic few of us understand!  (well, I guess that's not 
a joke really ;-)

What little I know:

The structure of the site is defined by the directory structure 
under build/data and the navigation and sub-navigation menus by 
the nav.yml and related files.  The overall page layout is 
defined closer to the top level and by the CSS.  Files are 
inherited from higher up in the directory structure, which is how 
the overall layout gets applied to all pages.  It's all somehow 
assembled by the yaml templates, and for a few pages/areas of the 
site also by some additional manipulations you can trace down by 
reading build/build.py.  For example, that builds PEPs 
semi-magically and also takes care of the news feed, mirrors 
list, and a few other things.  I look at this only when I need 
to.

On the live site, it's a different script that builds; see 
build/scripts/server-build.py.  Part of this is interleaving 
remaining pages from the old site w/ the new site content so 
unconverted pages still can be viewed.  Part of this is the need 
to auto-rebuild after Subversion commits.  Much of this code I've 
never really looked at in detail.

It's the layout inheritance and menus/submenus and page layout 
that can be confusing and I have to admit that I bungle around 
every time to find the right thing and don't have a complete 
understanding of it.

This and difficulty of installing the toolset and slowness to 
build the site are the key problems.  I think consensus is that 
we need a toolset redesign to address this, although it's up in 
the air how much has to be reworked -- for example, a make/scons 
dependency model might drastically speed up build, a single 
installer could make the tools easier to handle, and possibly 
some restructuring of how content, layout, and menus/submenus are 
specified might make that easier to understand.  

Of course we'ld also need understandible build error messages (w/ 
file / line number, for a start!), and a few other things, so it 
could well be we should abandon Pyramid entirely rather than 
tweaking it.  

But on the other hand, it might be easier to incrementally fix 
things than make a whole new toolset.  

You can see how it's easy to waffle about this (at least for me 
;-)

Andrew Kuchling has looked at using rest2web instead of Pyramid, 
and his experiment is checked into Subversion.  I haven't had 
time to look at it yet.

That's about all I know.  Hopefully it's useful.  Let me know if 
not...

- Stephan



More information about the Pydotorg-www mailing list