Re: [pygame] Pygame Website Rewrite: First alpha version ready for testing

[Tyler Laing]

Good to hear Devon. Good luck with your efforts!

-Tyler

On Mon, May 25, 2009 at 12:06 AM, Devon Scott-Tunkin
wrote:

>
> Thanks. She's right about the teal gradient:).
> The current design is VERY alpha, more basic layout to get started then
> anything and I'm really just playing with the colors at this point. Adobe
> kuler is also good for color schemes.
>
> Devon
>
> --- On Sun, 5/24/09, Tyler Laing  wrote:
>
> > From: Tyler Laing 
> > Subject: Re: [pygame] Pygame Website Rewrite: First alpha version ready
> for  testing
> > To: pygame-users@seul.org
> > Date: Sunday, May 24, 2009, 4:17 PM
> > Hi, lots of good work there. I sent
> > over your current design, as of sun may 24, 2:02 PM, to an
> > artist friend of mine. Also, I sent her the old design. She
> > had some advice and criticisms:
> >
> > "The gradient must disappear. On the
> > first one and on both of them the dark green does not match
> > the yellower-based greens. They need
> > to pick a theme of green thoughout. Not teal green and then
> > toss in some lime. It just doesn't match or coordinate
> > at all."
> >
> >
> > "What they really need is a
> > blend of the new site and the old. Because the new site is
> > too sparse and the old one is too busy without having
> > good-looking dividers."
> >
> > About the new site design: "Just make
> > sure that their greens match. The
> > white background's(for the new site) not bad but
> > it's pretty stark.  I'd say maybe the
> > best thing would be just a solid background, or just take
> > out that big image and do a simple texture on the background
> > paired with a smaller, more modest header image.
> > Also the tables in the white are very
> > boring. They should have better borders or a little
> > color."
> >
> >
> > If you want to use green, she suggests using this website
> > to pick a color scheme: http://bighugelabs.com/flickr/colors.php
> >
> > Just remember, if you don't like the advice, you
> > don't have to listen to her, but it is advice intended
> > to make the site better. :)
> >
> >
> > -Tyler
> >
> > On Sun, May 24, 2009 at 1:48 PM,
> > jug 
> > wrote:
> >
> > Hello,
> >
> >
> >
> > A first version of the rewritten pygame.org
> > website is ready for testing:
> >
> >
> >
> >http://pygameweb.no-ip.org/
> >
> >
> >
> > Main focus is on project management and user system. News
> > are also
> >
> > yet available. Feel free to register or log in with
> > guest/guest, create and
> >
> > edit projects, releases, screenshots and your profile or
> > vote the
> >
> > (dummy-)project of the month.
> >
> >
> >
> > Devon is still working on the design and often changes it.
> >
> >
> >
> > For development organization we use Trac and a mailing list
> > at google groups.
> >
> > More information at http://pygameweb.no-ip.org/trac/wiki/.
> >
> >
> >
> > If you spot any bugs or have an idea for this first version
> > thats not
> >
> > already on our ToDo list (http://pygameweb.no-ip.org/trac/wiki/ToDo)
> >
> > create a ticket.
> >
> >
> >
> > There was a problem with email and Trac, but now, all
> > registration
> >
> > and email stuff should work.
> >
> >
> >
> > Regards,
> >
> > Julian
> >
> >
> >
> >
> > --
> > Visit my blog at http://oddco.ca/zeroth/zblog
> >
> >
>
>
>
>


-- 
Visit my blog at http://oddco.ca/zeroth/zblog

Re: [pygame] Pygame Website Rewrite: First alpha version ready for testing

[Devon Scott-Tunkin]

Thanks. She's right about the teal gradient:).
The current design is VERY alpha, more basic layout to get started then 
anything and I'm really just playing with the colors at this point. Adobe kuler 
is also good for color schemes.

Devon

--- On Sun, 5/24/09, Tyler Laing  wrote:

> From: Tyler Laing 
> Subject: Re: [pygame] Pygame Website Rewrite: First alpha version ready for  
> testing
> To: pygame-users@seul.org
> Date: Sunday, May 24, 2009, 4:17 PM
> Hi, lots of good work there. I sent
> over your current design, as of sun may 24, 2:02 PM, to an
> artist friend of mine. Also, I sent her the old design. She
> had some advice and criticisms:
> 
> "The gradient must disappear. On the
> first one and on both of them the dark green does not match
> the yellower-based greens. They need
> to pick a theme of green thoughout. Not teal green and then
> toss in some lime. It just doesn't match or coordinate
> at all."
> 
> 
> "What they really need is a
> blend of the new site and the old. Because the new site is
> too sparse and the old one is too busy without having
> good-looking dividers."
> 
> About the new site design: "Just make
> sure that their greens match. The
> white background's(for the new site) not bad but
> it's pretty stark.  I'd say maybe the
> best thing would be just a solid background, or just take
> out that big image and do a simple texture on the background
> paired with a smaller, more modest header image.
> Also the tables in the white are very
> boring. They should have better borders or a little
> color."
> 
> 
> If you want to use green, she suggests using this website
> to pick a color scheme: http://bighugelabs.com/flickr/colors.php
> 
> Just remember, if you don't like the advice, you
> don't have to listen to her, but it is advice intended
> to make the site better. :)
> 
> 
> -Tyler
> 
> On Sun, May 24, 2009 at 1:48 PM,
> jug 
> wrote:
> 
> Hello,
> 
> 
> 
> A first version of the rewritten pygame.org
> website is ready for testing:
> 
> 
> 
>    http://pygameweb.no-ip.org/
> 
> 
> 
> Main focus is on project management and user system. News
> are also
> 
> yet available. Feel free to register or log in with
> guest/guest, create and
> 
> edit projects, releases, screenshots and your profile or
> vote the
> 
> (dummy-)project of the month.
> 
> 
> 
> Devon is still working on the design and often changes it.
> 
> 
> 
> For development organization we use Trac and a mailing list
> at google groups.
> 
> More information at http://pygameweb.no-ip.org/trac/wiki/.
> 
> 
> 
> If you spot any bugs or have an idea for this first version
> thats not
> 
> already on our ToDo list (http://pygameweb.no-ip.org/trac/wiki/ToDo)
> 
> create a ticket.
> 
> 
> 
> There was a problem with email and Trac, but now, all
> registration
> 
> and email stuff should work.
> 
> 
> 
> Regards,
> 
> Julian
> 
> 
> 
> 
> -- 
> Visit my blog at http://oddco.ca/zeroth/zblog
> 
> 

Re: [pygame] Pygame Website Rewrite: First alpha version ready for testing

[Tyler Laing]

Hi, lots of good work there. I sent over your current design, as of sun may
24, 2:02 PM, to an artist friend of mine. Also, I sent her the old design.
She had some advice and criticisms:

"The gradient must disappear. On the first one and on both of them the dark
green does not match the yellower-based greens. They need to pick a theme of
green thoughout. Not teal green and then toss in some lime. It just doesn't
match or coordinate at all."

"What they really need is a blend of the new site and the old. Because the
new site is too sparse and the old one is too busy without having
good-looking dividers."

About the new site design: "Just make sure that their greens match. The
white background's(for the new site) not bad but it's pretty stark.  I'd say
maybe the best thing would be just a solid background, or just take out that
big image and do a simple texture on the background paired with a smaller,
more modest header image. Also the tables in the white are very boring. They
should have better borders or a little color."

If you want to use green, she suggests using this website to pick a color
scheme: http://bighugelabs.com/flickr/colors.php

Just remember, if you don't like the advice, you don't have to listen to
her, but it is advice intended to make the site better. :)

-Tyler

On Sun, May 24, 2009 at 1:48 PM, jug  wrote:

> Hello,
>
> A first version of the rewritten pygame.org website is ready for testing:
>
>   http://pygameweb.no-ip.org/
>
> Main focus is on project management and user system. News are also
> yet available. Feel free to register or log in with guest/guest, create and
> edit projects, releases, screenshots and your profile or vote the
> (dummy-)project of the month.
>
> Devon is still working on the design and often changes it.
>
> For development organization we use Trac and a mailing list at google
> groups.
> More information at http://pygameweb.no-ip.org/trac/wiki/.
>
> If you spot any bugs or have an idea for this first version thats not
> already on our ToDo list (http://pygameweb.no-ip.org/trac/wiki/ToDo)
> create a ticket.
>
> There was a problem with email and Trac, but now, all registration
> and email stuff should work.
>
> Regards,
> Julian
>



-- 
Visit my blog at http://oddco.ca/zeroth/zblog

Re: [pygame] Pygame Website Rewrite: First alpha version ready for testing

[Evan Kroske]

A trivial design suggestion: I think that you should give an indication of
rollover on the main navigation bar. Right now, there's no indication that
you're hovering over a navigation link except the pointer cursor. I'm not
sure if an underline or a color change would be better, but there should be
some indicator, IMHO.Good job so far; I like the strong alignment.

Evan Kroske

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

Hi,

lxml parses the html to an xml ElementTree structure. It is also a validating 
parser, so a restrictived DTD could be provided to reject scripts. Or the tree 
could just be searched.

Lenard

Quoting René Dudfield :
> yeah should be mostly simple...
> 
> the website also uses some stuff to filter out things like javascript.
> Hopefully there is something similar available for python now.  Does lxml
> support that?  Failing that, will have to convert one of the ones from php.
> feedparser in python is pretty good for that... however it still has some
> problems.
> 
> It's a must for user submitted website content, no matter the markup
> language.
> 
> cu,
> 
> 
> 
> 
> On Mon, Apr 27, 2009 at 7:28 AM, Lenard Lindstrom  wrote:
> 
> > Sanitising will be simple. I have tried lxml. Of course there is also
> > beautifulsoup. Another issue is maintaining consistently across pages.
> Using
> >  tags doesn't work. Remembering what header level to use when is
> > bothersome. If new, more descriptive, header tags could be added that
> would
> > be great. And a preview function.
> >
> > Lenard
> >
> > René Dudfield wrote:
> >
> >> Hi,
> >>
> >> I suggest using the current one - rewritten in python, and fixing that
> >> bug.  I think that's the only code mangling bug it has?
> >>
> >> Yeah, the code in the wiki is probably best described as non-strict
> >> html... or just html... which is not strict itself.  The wiki does some
> >> sanitising on the html after entry.  It's only a few lines of code to add
> a
> >> gui editor like tinymce... so we could add that for those who don't want
> to
> >> use markup.
> >>
> >> cheers,
> >>
> >>
> >>
> >> On Mon, Apr 27, 2009 at 3:52 AM, Lenard Lindstrom
>  >> le...@telus.net>> wrote:
> >>
> >>Hi René,
> >>
> >>I don't know about Trac's tracking system but I find bugzilla
> >>difficult as it requires report generation. How to get a listing
> >>of recent bugs is not obvious.
> >>
> >>The html markup in the current wiki is not strict XHTML. We do
> >>want the new site to generate properly formed XHTML pages, or am I
> >>mistaken. Also Python code gets mangled, '<' replaced with '<'
> >>for  sections. This is probably a data entry problem though.
> >>But whatever wiki engine is chosen it has to handle this properly.
> >>Trac does. Do any of the html tag wikis handle it right? What
> >>alternate wiki do you suggest?
> >>
> >>Lenard
> >>
> >>
> >>
> >>René Dudfield wrote:
> >>
> >>hi,
> >>
> >>the main way we do bugs with pygame is through the mailing
> >>list.  The internet is a bug tracker.
> >>
> >>I wrote a blog post about the reasons why the mailing list is
> >>good, and what 'the internet is a bug tracker' means:
> >>http://renesd.blogspot.com/2008/02/bugs-search-not-categorise.html
> >>
> >>I personally think trac is a bit rubbish, and have been happy
> >>with James Paige hosting bugzilla for us.
> >>
> >>
> >>The current pygame wiki just uses simple html.  So should be
> >>fairly straight forward to convert... or we could just leave
> >>it in html.  Since most programmers know html anyway... way
> >>more than trac markup.
> >>
> >>
> >>
> >>
> >>
> >>
> >
> 


-- 
Lenard Lindstrom

Re: [pygame] PyGame Website Rewrite

[René Dudfield]

yeah should be mostly simple...

the website also uses some stuff to filter out things like javascript.
Hopefully there is something similar available for python now.  Does lxml
support that?  Failing that, will have to convert one of the ones from php.
feedparser in python is pretty good for that... however it still has some
problems.

It's a must for user submitted website content, no matter the markup
language.

cu,




On Mon, Apr 27, 2009 at 7:28 AM, Lenard Lindstrom  wrote:

> Sanitising will be simple. I have tried lxml. Of course there is also
> beautifulsoup. Another issue is maintaining consistently across pages. Using
>  tags doesn't work. Remembering what header level to use when is
> bothersome. If new, more descriptive, header tags could be added that would
> be great. And a preview function.
>
> Lenard
>
> René Dudfield wrote:
>
>> Hi,
>>
>> I suggest using the current one - rewritten in python, and fixing that
>> bug.  I think that's the only code mangling bug it has?
>>
>> Yeah, the code in the wiki is probably best described as non-strict
>> html... or just html... which is not strict itself.  The wiki does some
>> sanitising on the html after entry.  It's only a few lines of code to add a
>> gui editor like tinymce... so we could add that for those who don't want to
>> use markup.
>>
>> cheers,
>>
>>
>>
>> On Mon, Apr 27, 2009 at 3:52 AM, Lenard Lindstrom > le...@telus.net>> wrote:
>>
>>Hi René,
>>
>>I don't know about Trac's tracking system but I find bugzilla
>>difficult as it requires report generation. How to get a listing
>>of recent bugs is not obvious.
>>
>>The html markup in the current wiki is not strict XHTML. We do
>>want the new site to generate properly formed XHTML pages, or am I
>>mistaken. Also Python code gets mangled, '<' replaced with '<'
>>for  sections. This is probably a data entry problem though.
>>But whatever wiki engine is chosen it has to handle this properly.
>>Trac does. Do any of the html tag wikis handle it right? What
>>alternate wiki do you suggest?
>>
>>Lenard
>>
>>
>>
>>René Dudfield wrote:
>>
>>hi,
>>
>>the main way we do bugs with pygame is through the mailing
>>list.  The internet is a bug tracker.
>>
>>I wrote a blog post about the reasons why the mailing list is
>>good, and what 'the internet is a bug tracker' means:
>>http://renesd.blogspot.com/2008/02/bugs-search-not-categorise.html
>>
>>I personally think trac is a bit rubbish, and have been happy
>>with James Paige hosting bugzilla for us.
>>
>>
>>The current pygame wiki just uses simple html.  So should be
>>fairly straight forward to convert... or we could just leave
>>it in html.  Since most programmers know html anyway... way
>>more than trac markup.
>>
>>
>>
>>
>>
>>
>

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

Sanitising will be simple. I have tried lxml. Of course there is also 
beautifulsoup. Another issue is maintaining consistently across pages. 
Using  tags doesn't work. Remembering what header level to use when 
is bothersome. If new, more descriptive, header tags could be added that 
would be great. And a preview function.


Lenard

René Dudfield wrote:

Hi,

I suggest using the current one - rewritten in python, and fixing that 
bug.  I think that's the only code mangling bug it has?


Yeah, the code in the wiki is probably best described as non-strict 
html... or just html... which is not strict itself.  The wiki does 
some sanitising on the html after entry.  It's only a few lines of 
code to add a gui editor like tinymce... so we could add that for 
those who don't want to use markup.


cheers,



On Mon, Apr 27, 2009 at 3:52 AM, Lenard Lindstrom > wrote:


Hi René,

I don't know about Trac's tracking system but I find bugzilla
difficult as it requires report generation. How to get a listing
of recent bugs is not obvious.

The html markup in the current wiki is not strict XHTML. We do
want the new site to generate properly formed XHTML pages, or am I
mistaken. Also Python code gets mangled, '<' replaced with '<'
for  sections. This is probably a data entry problem though.
But whatever wiki engine is chosen it has to handle this properly.
Trac does. Do any of the html tag wikis handle it right? What
alternate wiki do you suggest?

Lenard



René Dudfield wrote:

hi,

the main way we do bugs with pygame is through the mailing
list.  The internet is a bug tracker.

I wrote a blog post about the reasons why the mailing list is
good, and what 'the internet is a bug tracker' means:
http://renesd.blogspot.com/2008/02/bugs-search-not-categorise.html

I personally think trac is a bit rubbish, and have been happy
with James Paige hosting bugzilla for us.


The current pygame wiki just uses simple html.  So should be
fairly straight forward to convert... or we could just leave
it in html.  Since most programmers know html anyway... way
more than trac markup.

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

Hi,

Thanks for the link to the bug tracker main page. A bug tracker may not 
be the most productive way to discover reported bug but what it does 
organize the repair effort. The mailing list has worked so far, but is 
not a good place to search out the current status of a bug. It also 
leaves us reliant on gmane.org, the only mailing list archive of the two 
listed with a proper search option. Even if Pygame does not get a bug 
tracker its website's framework will, or at least it will while under 
development.


Lenard


René Dudfield wrote:



On Mon, Apr 27, 2009 at 3:52 AM, Lenard Lindstrom > wrote:


Hi René,

I don't know about Trac's tracking system but I find bugzilla
difficult as it requires report generation. How to get a listing
of recent bugs is not obvious.



hi again,

This is the page which makes bugzilla easier to use.  It has links to 
the main things it's used for.

http://pygame.motherhamster.org/

I do note however that it has been maintained quite well by James 
Paige... in that the website hasn't had much downtime, and it isn't 
full of spam which seems to happen to some trac instances.


However, as I mentioned before I'm not really interested in bug 
trackers... preferring to search for bugs... so I'll leave that choice 
up to the rest of you.  I think there's more bugs reported if you 
search for 'pygame bug' (with only the last months/week/day entries 
listed) in google, than get reported in bug trackers.

eg.
http://www.google.com/search?q=pygame+bug&as_epq=&as_oq=&as_eq=&num=10&lr=&as_filetype=&ft=i&as_sitesearch=&as_qdr=w&as_rights=&as_occt=any&cr=&as_nlo=&as_nhi= 





cu,

Re: [pygame] PyGame Website Rewrite

[Marcus von Appen]

On, Sun Apr 26, 2009, Rene Dudfield wrote:

> On Mon, Apr 27, 2009 at 3:52 AM, Lenard Lindstrom  wrote:
> 
> > Hi René,
> >
> > I don't know about Trac's tracking system but I find bugzilla difficult as
> > it requires report generation. How to get a listing of recent bugs is not
> > obvious.
> >

Seconded - bugzilla is a pain due to various reasons, be it its high
complexity, the need to register and the really weird 'do not simply
file a bug' avoidance.

The main reason to use trac would be to have a lot of features in one
well-maintained and solid system. The wiki, milestone management and
such stuff (suitable for gsoc tasks and subprojects) and even a good bug
tracker are something to favour over an own hackish solution in my
opinion.

We won't need to implement a wiki ourselves as trac comes with it. A bug
tracker for those who do not like mailing lists would be given, - one
that does not require a master degree in report generation and bug
filing management to use it (*).

[...]
 
> I do note however that it has been maintained quite well by James Paige...
> in that the website hasn't had much downtime, and it isn't full of spam
> which seems to happen to some trac instances.

I only noticed that for projects, which are mostly stalled or where the
whole website seems to be completely unmaintained or dead.

If spam from anonymous users should go out of hands, we can change trac
to accept only registered users for bug reports (which'd be a pity,
though).
 
> However, as I mentioned before I'm not really interested in bug trackers...
> preferring to search for bugs... so I'll leave that choice up to the rest of

I'm preferring the mailing list, but some people do not want to
subscribe there or whatever and for those a small bug tracker is the
perfect solution.

(*) Many people, including me are pretty annoyed by bugzilla and a lot
do not even report bugs (including me) to projects like mozilla anymore,
as they do not want to register yet another account just for a short
bug, for which they even have to spend half a day on filling out all
boxes.

Regards
Marcus


pgpcK5jLztZse.pgp
Description: PGP signature

Re: [pygame] PyGame Website Rewrite

[René Dudfield]

On Mon, Apr 27, 2009 at 3:52 AM, Lenard Lindstrom  wrote:

> Hi René,
>
> I don't know about Trac's tracking system but I find bugzilla difficult as
> it requires report generation. How to get a listing of recent bugs is not
> obvious.
>


hi again,

This is the page which makes bugzilla easier to use.  It has links to the
main things it's used for.
http://pygame.motherhamster.org/

I do note however that it has been maintained quite well by James Paige...
in that the website hasn't had much downtime, and it isn't full of spam
which seems to happen to some trac instances.

However, as I mentioned before I'm not really interested in bug trackers...
preferring to search for bugs... so I'll leave that choice up to the rest of
you.  I think there's more bugs reported if you search for 'pygame bug'
(with only the last months/week/day entries listed) in google, than get
reported in bug trackers.
eg.
http://www.google.com/search?q=pygame+bug&as_epq=&as_oq=&as_eq=&num=10&lr=&as_filetype=&ft=i&as_sitesearch=&as_qdr=w&as_rights=&as_occt=any&cr=&as_nlo=&as_nhi=



cu,

Re: [pygame] PyGame Website Rewrite

[René Dudfield]

hi,

sorry if my emails come across as not being thankful, or appreciative of
your efforts... little pygame is my baby(and is many other peoples baby too
of course), so I'm maybe overly protective of it.

Thanks partly to you(and others), and your enthusiasm the project seems like
it might actually get done, and it is very much appreciated by me and
everyone else I'm sure.


On Sat, Apr 25, 2009 at 8:52 PM, jug  wrote:

> Hello,
>
> I'm kinda amazed about some points:
>
> 1) Did anyone read my concept?
>   Some of the discussed ideas here I had before but no one cared.
>

> 2) I created a trac an you said "nice!" and created a Google project.
>

Thanks for progressive way you went forward and are getting things done.

However, this will be a team effort, and we need to discuss our plan before
doing things.

I don't really know you, and I was a little worried you might disappear in a
week/month.  Whereas a google site won't just disappear.  I'm not saying
that you would disappear... just that it's very common for people to
disappear on open source projects.

There's no need to rush into making a decision about what we want to do with
the website.  One of the main goals of the rewrite was so that more pygame
contributors could modify the websites code.  Three active contributors to
pygame have expressed a preference for using cherrypy(pymike, nick, and I).
pymike doesn't write code for pygame itself, but has put more games/projects
on the pygame website than almost any other person(him and Ian seem to be in
a race to produce the most things).  pymike also expressed interest in
working on the website in late January.

The three main 'clients' for this project are...
 - the coders who make pygame,
 - the people who make games with pygame,
 - and the people who contribute to the website.

So whilst it's important that the people making the website are happy with
the choice of tools, it's also important the other main groups are happy
with the choices.

As one of the people contributing to pygame for the longest time, I want to
make sure the website is done nicely, and is an improvement to the current
one.  It's probably the most important part of pygame, so I think it
deserves some more discussion.






> 3) This project was an gsoc candidate and AFAIK all applicants wanted
>   to use Django. At least 2 of them (Orcun and me) would like to do it
>   even without google. Now you say "let's do it with cherrypy" because
>   you don't know Django. Hm. I my view, both - Django and cherrypy -
>   are mighty enough for our needs, thus its a relig. question of faith. But
> you
>   asked so to do it. So, here we are! We have time and (only) want to do it
>   with Django, cause we don't know cherrypy as you don't know Django.
>   Maybe here are some php-experts why do it with php?
>


Yes, however there's also other people interested in working on the website.

Rather than have you decide what is used, we need to have a discussion.  I
didn't know you didn't like cherrypy or not... and I don't know yet what
other people want to use.

btw, I have looked at django in the past.  Here you can see a post I made in
2006 about some security problems I found in Django
http://renesd.blogspot.com/2006/08/django-security.html  I mention this just
to show that I'm not entirely unfamiliar with django.

Let me explain some history, and further outline parts of the current
website...




The current website is made with PHP and some website technology made by
Phil which he used to make dozens of websites professionaly.  This is what
Phil chose to use as the website maintainer in early 2005.  This time around
we wanted to make it a team effort, and to make it in python.  Last time
we(the mailing list and Pete Shinners) decided to let whoever the website
maintainer is make it in whatever they wanted to make it with.  The main
goal was to get a good website.

This time we decided it would be better to do it in python, and also have a
team of website maintainers.  Since not so many pygame developers people
know PHP, and that has meant that it's been a bit difficult for us to make
changes... we had to bother Phil mostly to change things.  Luckily the
website has worked fairly well without needing to make all that many changes
to the code.  It's pretty amazing really what Phil has done with the
website, and especially considering how it has worked for many years without
many code changes, and is now a very popular website.

Before 2005, the project was more Pete Shinners personal project with a
bunch of helpers... now it has evolved into group project with 8 or so main
fairly active contributors, and a whole bunch of sometimes contributors...
with millions of downloads, 10,000's of people using it to make things, and
millions of people playing the games made with pygame.  There's over 1100
projects listed on pygame.org.  Now both Pete, and Phil have somewhat moved
onto other things from pygame, but both pop their heads in occasionally...
and

Re: [pygame] PyGame Website Rewrite

[René Dudfield]

Hi,

I suggest using the current one - rewritten in python, and fixing that bug.
I think that's the only code mangling bug it has?

Yeah, the code in the wiki is probably best described as non-strict html...
or just html... which is not strict itself.  The wiki does some sanitising
on the html after entry.  It's only a few lines of code to add a gui editor
like tinymce... so we could add that for those who don't want to use markup.

cheers,



On Mon, Apr 27, 2009 at 3:52 AM, Lenard Lindstrom  wrote:

> Hi René,
>
> I don't know about Trac's tracking system but I find bugzilla difficult as
> it requires report generation. How to get a listing of recent bugs is not
> obvious.
>
> The html markup in the current wiki is not strict XHTML. We do want the new
> site to generate properly formed XHTML pages, or am I mistaken. Also Python
> code gets mangled, '<' replaced with '<' for  sections. This is
> probably a data entry problem though. But whatever wiki engine is chosen it
> has to handle this properly. Trac does. Do any of the html tag wikis handle
> it right? What alternate wiki do you suggest?
>
> Lenard
>
>
>
> René Dudfield wrote:
>
>> hi,
>>
>> the main way we do bugs with pygame is through the mailing list.  The
>> internet is a bug tracker.
>>
>> I wrote a blog post about the reasons why the mailing list is good, and
>> what 'the internet is a bug tracker' means:
>> http://renesd.blogspot.com/2008/02/bugs-search-not-categorise.html
>>
>> I personally think trac is a bit rubbish, and have been happy with James
>> Paige hosting bugzilla for us.
>>
>>
>> The current pygame wiki just uses simple html.  So should be fairly
>> straight forward to convert... or we could just leave it in html.  Since
>> most programmers know html anyway... way more than trac markup.
>>
>>
>>
>>
>

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

Hi René,

I don't know about Trac's tracking system but I find bugzilla difficult 
as it requires report generation. How to get a listing of recent bugs is 
not obvious.


The html markup in the current wiki is not strict XHTML. We do want the 
new site to generate properly formed XHTML pages, or am I mistaken. Also 
Python code gets mangled, '<' replaced with '<' for  sections. 
This is probably a data entry problem though. But whatever wiki engine 
is chosen it has to handle this properly. Trac does. Do any of the html 
tag wikis handle it right? What alternate wiki do you suggest?


Lenard


René Dudfield wrote:

hi,

the main way we do bugs with pygame is through the mailing list.  The 
internet is a bug tracker.


I wrote a blog post about the reasons why the mailing list is good, 
and what 'the internet is a bug tracker' means:

http://renesd.blogspot.com/2008/02/bugs-search-not-categorise.html

I personally think trac is a bit rubbish, and have been happy with 
James Paige hosting bugzilla for us.



The current pygame wiki just uses simple html.  So should be fairly 
straight forward to convert... or we could just leave it in html.  
Since most programmers know html anyway... way more than trac markup.

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

jug wrote:


Hi,

using Trac with google SVN is not directly provided, but could be 
done. You need
to mirror the repo on the server where Trac is running on. Because you 
have

no access to SVN-hook scripts at google it's a bit tricky. Have a look at
http://rc98.net/googsvnsync. I'm not a SVN expert so who could 
undertake this?


We are still waiting for the current database structure, but I think 
it will be
possible to import old wiki data. At http://trac-hacks.org/wiki/script 
are some
scripts to import wiki data from other wikis (eg. MoinToTrac). I think 
we could

write an equal script.

- Jug
Not having direct google SVN access from Trac is not a big deal. And 
certainly something can be figured out with for the wiki pages. It is 
not a new problem.


--
Lenard Lindstrom

Re: [pygame] PyGame Website Rewrite

[René Dudfield]

hi,

the main way we do bugs with pygame is through the mailing list.  The
internet is a bug tracker.

I wrote a blog post about the reasons why the mailing list is good, and what
'the internet is a bug tracker' means:
http://renesd.blogspot.com/2008/02/bugs-search-not-categorise.html

I personally think trac is a bit rubbish, and have been happy with James
Paige hosting bugzilla for us.


The current pygame wiki just uses simple html.  So should be fairly straight
forward to convert... or we could just leave it in html.  Since most
programmers know html anyway... way more than trac markup.



On Sun, Apr 26, 2009 at 2:23 PM, Nirav Patel  wrote:

> All I have to add to this is that having real bug tracking integrated
> with the SVN is a huge plus and if possible, should be put into place
> as soon as possible.  That is, having Trac up on dev.pygame.org before
> starting the web development work for use with both the website
> project and Pygame in general would be nice.
>
> I really dislike the Bugzilla we are currently using, and judging by
> the lack of activity on it, I imagine many others do too.
>
> Nirav
>
> On Sat, Apr 25, 2009 at 11:59 PM, Lenard Lindstrom 
> wrote:
> > Marcus von Appen wrote:
> >>
> >> After discussing certain things with Julian, something like this might
> >> make the most sense:
> >>
> >> SVN hosting on google.
> >>
> >> Trac (which I'd prefer over google's homebrewn software) on
> >> dev.pygame.org.
> >>
> >> Why that? First of all, one of the website requirements is to have a bug
> >> tracker and wiki integrated instead of having anything hosted on
> >> different domains as it is at the moment.
> >>
> >> dev.pygame.org could act as central platform for pygame-related
> >> development. Users can keep track of pygame projects, which are in a
> >> planning and early development state and the trac system running there
> >> can act as routing station to the different SVN repositories hosted
> >> elsewhere (google, pygame, ...).
> >>
> >> In the long term, this also allows us to have a development wiki and bug
> >> tracking already around and the only thing left to do would be to
> >> integrate them seamlessly into the final pygame.org website.
> >>
> >> For the current time, we could redirect dev.pygame.org to Julian's
> >> webserver, then, once trac is up and running on pygame.org (which
> should
> >> be relatively easy to be realised), let it point to the local trac. That
> >> way we have no dead URL mess and people do not need to visit various
> >> sites (and create different accounts) just to file bugs for (either)
> >> pygame project.
> >>
> >> We also do not have the data scattered ony google's wiki, pygame.organd
> >> wherever else.
> >>
> >>
> >
> > Keeping the web site development on a separate site, google, seem
> > appropriate for now. I have just been looking again at Trac and at first
> it
> > looks like a good choice. The wiki has a clean markup that accepts Python
> > code without mangling it. But I have two questions. One, how easy will it
> be
> > to import the existing Pygame wiki pages into Trac? Two, can we really
> use
> > the Trac with the Web SVN and Pygame SVN? (*)
> >
> > Lenard
> >
> > (*) I believe no to the first, yes to the second
> > (http://trac.edgewall.org/wiki/TracInstall#OptionalRequirements).
> >
>

Re: [pygame] PyGame Website Rewrite

[jug]

Hi,

I just got the DjangoAuthIntegration (1) Trac plugin working. With this
plugin, you can login to Django, go to Trac and are logged in (without
reentering username and password). After logging out at Django,
you are logged out with Trac, too. Thats really cool.
Now need some testing.

-Jug


(1) http://trac-hacks.org/wiki/DjangoAuthIntegration

Re: [pygame] PyGame Website Rewrite

[jug]

Hi,

using Trac with google SVN is not directly provided, but could be done. 
You need

to mirror the repo on the server where Trac is running on. Because you have
no access to SVN-hook scripts at google it's a bit tricky. Have a look at
http://rc98.net/googsvnsync. I'm not a SVN expert so who could undertake 
this?


We are still waiting for the current database structure, but I think it 
will be
possible to import old wiki data. At http://trac-hacks.org/wiki/script 
are some
scripts to import wiki data from other wikis (eg. MoinToTrac). I think 
we could

write an equal script.

- Jug

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

I agree that a Pygame bug tracker on the Pygame site is a priority. Trac 
looks good for that. The wiki will be useful as well. But the Trac 
subversion features will be useless with a google SVN for the web site 
development. So we will have to use whatever google offers. But I 
believe we can set it up for Pygame's SVN.


Lenard

Nirav Patel wrote:

All I have to add to this is that having real bug tracking integrated
with the SVN is a huge plus and if possible, should be put into place
as soon as possible.  That is, having Trac up on dev.pygame.org before
starting the web development work for use with both the website
project and Pygame in general would be nice.

I really dislike the Bugzilla we are currently using, and judging by
the lack of activity on it, I imagine many others do too.

Nirav

On Sat, Apr 25, 2009 at 11:59 PM, Lenard Lindstrom  wrote:
  

Marcus von Appen wrote:


After discussing certain things with Julian, something like this might
make the most sense:

SVN hosting on google.

Trac (which I'd prefer over google's homebrewn software) on
dev.pygame.org.

Why that? First of all, one of the website requirements is to have a bug
tracker and wiki integrated instead of having anything hosted on
different domains as it is at the moment.

dev.pygame.org could act as central platform for pygame-related
development. Users can keep track of pygame projects, which are in a
planning and early development state and the trac system running there
can act as routing station to the different SVN repositories hosted
elsewhere (google, pygame, ...).

In the long term, this also allows us to have a development wiki and bug
tracking already around and the only thing left to do would be to
integrate them seamlessly into the final pygame.org website.

For the current time, we could redirect dev.pygame.org to Julian's
webserver, then, once trac is up and running on pygame.org (which should
be relatively easy to be realised), let it point to the local trac. That
way we have no dead URL mess and people do not need to visit various
sites (and create different accounts) just to file bugs for (either)
pygame project.

We also do not have the data scattered ony google's wiki, pygame.org and
wherever else.


  

Keeping the web site development on a separate site, google, seem
appropriate for now. I have just been looking again at Trac and at first it
looks like a good choice. The wiki has a clean markup that accepts Python
code without mangling it. But I have two questions. One, how easy will it be
to import the existing Pygame wiki pages into Trac? Two, can we really use
the Trac with the Web SVN and Pygame SVN? (*)

Lenard

(*) I believe no to the first, yes to the second
(http://trac.edgewall.org/wiki/TracInstall#OptionalRequirements).

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

Are we already at the point where we can choose a framework? I am not 
experienced enough in this area to make a recommendation. I will look at 
them more closely. Django is favored at the new Pygame web site 
development Trac. Of major consideration is the ease with which the 
content of the existing site can be ported to the new site. I cannot 
even comment on that as I don't know how the existing site is 
implemented, though I guess Python is involved somewhere.


As for what I can contribute, I am taking this more as a learning 
opportunity than anything. I could probably write applications to port 
information and maybe convert wiki to pages if something doesn't already 
exist. But I will leave the framework stuff to others. I have also 
played around a bit with PovRay so could create some simple 3D effect 
controls like in the midi.py Pygame example.


Lenard


René Dudfield wrote:

Hi,

very detailed emails from Marcus and Nicholas...

a few related points below.


I'd be interested in knowing what jug, and orcun think of using 
Django?  Also what they think of a cherrypy based stack?


Also, what are the preferences of Lenard, Devon, pymike, and anyone 
else who is interested in contributing?  Please state the level of 
commitment you're willing to make, and also which option(s) you'd be 
happy using.





- The main author of cherrypy(Robert Brewer) said he'd help us with 
any major issues we had, and so did some other cherrypy mailing list 
people.  The cherrypy mailing list is also more active than the pygame 
one, so I'm sure we won't have any issues with docs or help.


- documentation is extensive for cherrypy(it's a 10 year old project, 
in it's third generation).


- we would have to choose a stack.  The stack Nicholas mentioned seems 
pretty common, cherrypy + sqlalchemy + genshi + formencode/formalchemy 
+ pygame of course for imaging... and joysick control of the 
website.   So that is the stack we would be chosing.


- cherrypy code seems cleaner... as it's just python objects.

class MySite(object):
def index(self):
return "hello world!"

def news(self, id=None):
if id is None:
return main_news()
else:
return specific_news(id)

index.exposed = True
news.exposed = True

This creates these urls by default:
/
/index
/news
/news/10
/news?id=10


- cherrypy has less code compared to django, and is changing less.

- django is usually run using apache modpython or mod_wsgi, or even 
with cherrypy(or other wsgi server).  They don't recommend using the 
bundled django webserver.  Whereas cherrypy is considered one of, if 
not the best python web servers.  With cherrypy you use the same 
webserver for development, and for production.


- you can run cherrypy inside a pygame application.  Cherrypy doesn't 
control the main loop if you don't want it to.


- there are more wsgi components than there are pinax apps.  Also 
pinax apps should theoretically be able to play with wsgi.  I'm pretty 
sure you can use django apps as wsgi components now too.

Re: [pygame] PyGame Website Rewrite

[Nirav Patel]

All I have to add to this is that having real bug tracking integrated
with the SVN is a huge plus and if possible, should be put into place
as soon as possible.  That is, having Trac up on dev.pygame.org before
starting the web development work for use with both the website
project and Pygame in general would be nice.

I really dislike the Bugzilla we are currently using, and judging by
the lack of activity on it, I imagine many others do too.

Nirav

On Sat, Apr 25, 2009 at 11:59 PM, Lenard Lindstrom  wrote:
> Marcus von Appen wrote:
>>
>> After discussing certain things with Julian, something like this might
>> make the most sense:
>>
>> SVN hosting on google.
>>
>> Trac (which I'd prefer over google's homebrewn software) on
>> dev.pygame.org.
>>
>> Why that? First of all, one of the website requirements is to have a bug
>> tracker and wiki integrated instead of having anything hosted on
>> different domains as it is at the moment.
>>
>> dev.pygame.org could act as central platform for pygame-related
>> development. Users can keep track of pygame projects, which are in a
>> planning and early development state and the trac system running there
>> can act as routing station to the different SVN repositories hosted
>> elsewhere (google, pygame, ...).
>>
>> In the long term, this also allows us to have a development wiki and bug
>> tracking already around and the only thing left to do would be to
>> integrate them seamlessly into the final pygame.org website.
>>
>> For the current time, we could redirect dev.pygame.org to Julian's
>> webserver, then, once trac is up and running on pygame.org (which should
>> be relatively easy to be realised), let it point to the local trac. That
>> way we have no dead URL mess and people do not need to visit various
>> sites (and create different accounts) just to file bugs for (either)
>> pygame project.
>>
>> We also do not have the data scattered ony google's wiki, pygame.org and
>> wherever else.
>>
>>
>
> Keeping the web site development on a separate site, google, seem
> appropriate for now. I have just been looking again at Trac and at first it
> looks like a good choice. The wiki has a clean markup that accepts Python
> code without mangling it. But I have two questions. One, how easy will it be
> to import the existing Pygame wiki pages into Trac? Two, can we really use
> the Trac with the Web SVN and Pygame SVN? (*)
>
> Lenard
>
> (*) I believe no to the first, yes to the second
> (http://trac.edgewall.org/wiki/TracInstall#OptionalRequirements).
>

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

Marcus von Appen wrote:

After discussing certain things with Julian, something like this might
make the most sense:

SVN hosting on google.

Trac (which I'd prefer over google's homebrewn software) on dev.pygame.org.

Why that? First of all, one of the website requirements is to have a bug
tracker and wiki integrated instead of having anything hosted on
different domains as it is at the moment.

dev.pygame.org could act as central platform for pygame-related
development. Users can keep track of pygame projects, which are in a
planning and early development state and the trac system running there
can act as routing station to the different SVN repositories hosted
elsewhere (google, pygame, ...).

In the long term, this also allows us to have a development wiki and bug
tracking already around and the only thing left to do would be to
integrate them seamlessly into the final pygame.org website.

For the current time, we could redirect dev.pygame.org to Julian's
webserver, then, once trac is up and running on pygame.org (which should
be relatively easy to be realised), let it point to the local trac. That
way we have no dead URL mess and people do not need to visit various
sites (and create different accounts) just to file bugs for (either)
pygame project.

We also do not have the data scattered ony google's wiki, pygame.org and
wherever else.

  
Keeping the web site development on a separate site, google, seem 
appropriate for now. I have just been looking again at Trac and at first 
it looks like a good choice. The wiki has a clean markup that accepts 
Python code without mangling it. But I have two questions. One, how easy 
will it be to import the existing Pygame wiki pages into Trac? Two, can 
we really use the Trac with the Web SVN and Pygame SVN? (*)


Lenard

(*) I believe no to the first, yes to the second 
(http://trac.edgewall.org/wiki/TracInstall#OptionalRequirements).

Re: [pygame] PyGame Website Rewrite

[Evan Kroske]

jug wrote:


One of the few weaknesses of Django
is that it does not support subdomains. Thus, pygame.org/dev would
be much easier to handle.


Unless I misunderstood, everybody was saying that someone should create 
a subdomain with the server administrator tools and simply run Django 
from there. I don't think they want Django running in the top-level web 
directory and creating a dev subdomain. If you're saying that Django 
can't be confined to a single directory and that it must be run from the 
top-level web directory, I have nothing to add.


Regards,
Evan Kroske

Re: [pygame] PyGame Website Rewrite

[sheepjxx]

Intresting, I just start to study Django, I think it is really a
nice tools.

--
From: "jug" 
Sent: Saturday, April 25, 2009 9:26 PM
To: 
Subject: Re: [pygame] PyGame Website Rewrite


There's one problem remaining. One of the few weaknesses of Django
is that it does not support subdomains. Thus, pygame.org/dev would
be much easier to handle.
To concretize, please specify the structure again. What would Trac be
used for? Replace the current wiki and add a ticket system for bug-tracing
and more (enhancements, etc)?
So, the rough structure would be

Django
 - News
 - Flatpages
 - Projects
Trac
 - Wiki
 - Ticket system
 - code browser
 - (maybe more?)

I'm going to test the django-trac thing today. If we use now my Trac 
please
try to keep the concept up to date and edit it with our discussion 
results.


- Jug



<http://www.dict.cc/englisch-deutsch/weakness.html>

Re: [pygame] PyGame Website Rewrite

[jug]

There's one problem remaining. One of the few weaknesses of Django
is that it does not support subdomains. Thus, pygame.org/dev would
be much easier to handle.
To concretize, please specify the structure again. What would Trac be
used for? Replace the current wiki and add a ticket system for bug-tracing
and more (enhancements, etc)?
So, the rough structure would be

Django
 - News
 - Flatpages
 - Projects
Trac
 - Wiki
 - Ticket system
 - code browser
 - (maybe more?)

I'm going to test the django-trac thing today. If we use now my Trac please
try to keep the concept up to date and edit it with our discussion results.

- Jug

Re: [pygame] PyGame Website Rewrite

[Nicholas Dudfield]

Marcus von Appen wrote:

On, Sat Apr 25, 2009, Nicholas Dudfield wrote:

  
I doubt I'd be contributing in any form whatsoever if Django is used.  I 
have no real interest in learning it.


If Robert Brewer has personally promised assistance that would be a very 
good case for using CherryPy.



Well, I'd like to keep the decision those, who will do the major work on
the whole website system, which probably will be Julian and Orcun.

If they both say, Django is their preferred target system (and the GSoC
proposals were written that way) as they have a lot of expertise, we
should not insist on CherryPy :-).

Regards
Marcus
  

In full:
"""
I doubt I'd be contributing in any form whatsoever if Django is used.  I 
have no real interest in learning it.


If Robert Brewer has personally promised assistance that would be a very 
good case for using CherryPy.


*As time permits I might* be able to help somewhat if a CherryPy stack 
is used.


I personally much prefer CherryPy + Co over what I have seen of Django 
*but I doubt I'll be contributing much compared to others.*"""



I actually took time out  of my day to argue the case for using Django.

Re: [pygame] PyGame Website Rewrite

[Nicholas Dudfield]

I'm actually for you guys using Django.

"""
If most of the people that are motivated to do the work already have experience
with Django I think it would just be more work for all involved using a custom
CherryPy stack.

Contributors would have to follow the evolving `framework`. They'd have to spend
time documenting it if they wanted to make it easy for more people to
contribute. They'd likely waste time arguing over the best ways of doing things
and which components to use. Would it ever get done? Or would everyone just get
sick of it?

For an opensource project with potentially quite a few people working on it (The
more the better right?) then I'd say Django would be a good fit due to the
`free` unified documentation and resources surrounding it and the fact that
every one is on the same page.
"""

On Sat, Apr 25, 2009 at 8:52 PM, jug  wrote:
> Hello,
>
> I'm kinda amazed about some points:
>
> 1) Did anyone read my concept?
>   Some of the discussed ideas here I had before but no one cared.
>
> 2) I created a trac an you said "nice!" and created a Google project.
>
> 3) This project was an gsoc candidate and AFAIK all applicants wanted
>   to use Django. At least 2 of them (Orcun and me) would like to do it
>   even without google. Now you say "let's do it with cherrypy" because
>   you don't know Django. Hm. I my view, both - Django and cherrypy -
>   are mighty enough for our needs, thus its a relig. question of faith. But
> you
>   asked so to do it. So, here we are! We have time and (only) want to do it
>   with Django, cause we don't know cherrypy as you don't know Django.
>   Maybe here are some php-experts why do it with php?
>
> 4) Even if you don't know Django, you can participate by helping to develop
>   the concept, writing specific requirements, care about design, read the
>   old code, transfer it and write new templates (Django templates are really
>   easy to learn). If we use Trac the way things are going, there will be
> some
>   work on adapting it by editing the Trac templates and style to make it fit
>   into the whole page. Then, care about plugins that could be useful or
>   necessary (auth, notification, feeds, irc-announcer, ...). Be sure you can
> help
>   us even when using Django for the backend.
>
> Regards
> Jug
>
> PS, well, I'm a slow writer, so I agree with Marcus.
>
>
>

Re: [pygame] PyGame Website Rewrite

[jug]

Hello,

I'm kinda amazed about some points:

1) Did anyone read my concept?
   Some of the discussed ideas here I had before but no one cared.

2) I created a trac an you said "nice!" and created a Google project.

3) This project was an gsoc candidate and AFAIK all applicants wanted
   to use Django. At least 2 of them (Orcun and me) would like to do it
   even without google. Now you say "let's do it with cherrypy" because
   you don't know Django. Hm. I my view, both - Django and cherrypy -
   are mighty enough for our needs, thus its a relig. question of 
faith. But you
   asked so to do it. So, here we are! We have time and (only) want to 
do it

   with Django, cause we don't know cherrypy as you don't know Django.
   Maybe here are some php-experts why do it with php?

4) Even if you don't know Django, you can participate by helping to develop
   the concept, writing specific requirements, care about design, read the
   old code, transfer it and write new templates (Django templates are 
really
   easy to learn). If we use Trac the way things are going, there will 
be some
   work on adapting it by editing the Trac templates and style to make 
it fit

   into the whole page. Then, care about plugins that could be useful or
   necessary (auth, notification, feeds, irc-announcer, ...). Be sure 
you can help

   us even when using Django for the backend.

Regards
Jug

PS, well, I'm a slow writer, so I agree with Marcus.

Re: [pygame] PyGame Website Rewrite

[Nicholas Dudfield]

On, Sat Apr 25, 2009, Nicholas Dudfield wrote:

  
I doubt I'd be contributing in any form whatsoever if Django is used.  I 
have no real interest in learning it.


If Robert Brewer has personally promised assistance that would be a very 
good case for using CherryPy.



Well, I'd like to keep the decision those, who will do the major work on
the whole website system, which probably will be Julian and Orcun.

If they both say, Django is their preferred target system (and the GSoC
proposals were written that way) as they have a lot of expertise, we
should not insist on CherryPy :-).

Regards
Marcus
  
"Happy programmers are motivated and *productive* programmers" I meant 
to write but I had a brain malfunction.

Re: [pygame] PyGame Website Rewrite

[Nicholas Dudfield]

Marcus von Appen wrote:

Well, I'd like to keep the decision those, who will do the major work on
the whole website system, which probably will be Julian and Orcun.
  
I am in complete agreeance.  Happy programmers are motivated and 
programmers./

/

Re: [pygame] PyGame Website Rewrite

[Marcus von Appen]

On, Sat Apr 25, 2009, Nicholas Dudfield wrote:

> I doubt I'd be contributing in any form whatsoever if Django is used.  I 
> have no real interest in learning it.
> 
> If Robert Brewer has personally promised assistance that would be a very 
> good case for using CherryPy.

Well, I'd like to keep the decision those, who will do the major work on
the whole website system, which probably will be Julian and Orcun.

If they both say, Django is their preferred target system (and the GSoC
proposals were written that way) as they have a lot of expertise, we
should not insist on CherryPy :-).

Regards
Marcus


pgpeybUYTDnYX.pgp
Description: PGP signature

Re: [pygame] PyGame Website Rewrite

[Marcus von Appen]

On, Fri Apr 24, 2009, Rene Dudfield wrote:

[...]

> >
> >  Also, is it possible to do this at google code instead?
> >>http://code.google.com/p/pygame/
> >>
> >
> > Sounds reasonable - google already has the whole functionality for the
> > project,
> > Julian currently hosts privately. It might be good to use google's wiki
> > there
> > and a seperate website SVN branch. Especially since the final system could
> > be
> > adopted by other community-driven projects.
> >
> >
> Also lots of people already have google accounts on there, and it's not
> hosted on someones personal server.
> 
> Keeping it separate from the main pygame svn makes sense, since it's
> probably going to be a separate group of people, and also it's fairly easy
> to allow access to it.

After discussing certain things with Julian, something like this might
make the most sense:

SVN hosting on google.

Trac (which I'd prefer over google's homebrewn software) on dev.pygame.org.

Why that? First of all, one of the website requirements is to have a bug
tracker and wiki integrated instead of having anything hosted on
different domains as it is at the moment.

dev.pygame.org could act as central platform for pygame-related
development. Users can keep track of pygame projects, which are in a
planning and early development state and the trac system running there
can act as routing station to the different SVN repositories hosted
elsewhere (google, pygame, ...).

In the long term, this also allows us to have a development wiki and bug
tracking already around and the only thing left to do would be to
integrate them seamlessly into the final pygame.org website.

For the current time, we could redirect dev.pygame.org to Julian's
webserver, then, once trac is up and running on pygame.org (which should
be relatively easy to be realised), let it point to the local trac. That
way we have no dead URL mess and people do not need to visit various
sites (and create different accounts) just to file bugs for (either)
pygame project.

We also do not have the data scattered ony google's wiki, pygame.org and
wherever else.

Regards
Marcus


pgpcQIJeqnXnQ.pgp
Description: PGP signature

Re: [pygame] PyGame Website Rewrite

[Nicholas Dudfield]

I doubt I'd be contributing in any form whatsoever if Django is used.  I 
have no real interest in learning it.


If Robert Brewer has personally promised assistance that would be a very 
good case for using CherryPy.


As time permits I might be able to help somewhat if a CherryPy stack is 
used.


I personally much prefer CherryPy + Co over what I have seen of Django 
but I doubt I'll be contributing much compared to others.

Hi,

very detailed emails from Marcus and Nicholas...

a few related points below.


I'd be interested in knowing what jug, and orcun think of using 
Django?  Also what they think of a cherrypy based stack?


Also, what are the preferences of Lenard, Devon, pymike, and anyone 
else who is interested in contributing?  Please state the level of 
commitment you're willing to make, and also which option(s) you'd be 
happy using.





- The main author of cherrypy(Robert Brewer) said he'd help us with 
any major issues we had, and so did some other cherrypy mailing list 
people.  The cherrypy mailing list is also more active than the pygame 
one, so I'm sure we won't have any issues with docs or help.


- documentation is extensive for cherrypy(it's a 10 year old project, 
in it's third generation).


- we would have to choose a stack.  The stack Nicholas mentioned seems 
pretty common, cherrypy + sqlalchemy + genshi + formencode/formalchemy 
+ pygame of course for imaging... and joysick control of the 
website.   So that is the stack we would be chosing.


- cherrypy code seems cleaner... as it's just python objects.

class MySite(object):
def index(self):
return "hello world!"

def news(self, id=None):
if id is None:
return main_news()
else:
return specific_news(id)

index.exposed = True
news.exposed = True

This creates these urls by default:
/
/index
/news
/news/10
/news?id=10


- cherrypy has less code compared to django, and is changing less.

- django is usually run using apache modpython or mod_wsgi, or even 
with cherrypy(or other wsgi server).  They don't recommend using the 
bundled django webserver.  Whereas cherrypy is considered one of, if 
not the best python web servers.  With cherrypy you use the same 
webserver for development, and for production.


- you can run cherrypy inside a pygame application.  Cherrypy doesn't 
control the main loop if you don't want it to.


- there are more wsgi components than there are pinax apps.  Also 
pinax apps should theoretically be able to play with wsgi.  I'm pretty 
sure you can use django apps as wsgi components now too.

Re: [pygame] PyGame Website Rewrite

[René Dudfield]

Hi,

very detailed emails from Marcus and Nicholas...

a few related points below.


I'd be interested in knowing what jug, and orcun think of using Django?
Also what they think of a cherrypy based stack?

Also, what are the preferences of Lenard, Devon, pymike, and anyone else who
is interested in contributing?  Please state the level of commitment you're
willing to make, and also which option(s) you'd be happy using.




- The main author of cherrypy(Robert Brewer) said he'd help us with any
major issues we had, and so did some other cherrypy mailing list people.
The cherrypy mailing list is also more active than the pygame one, so I'm
sure we won't have any issues with docs or help.

- documentation is extensive for cherrypy(it's a 10 year old project, in
it's third generation).

- we would have to choose a stack.  The stack Nicholas mentioned seems
pretty common, cherrypy + sqlalchemy + genshi + formencode/formalchemy +
pygame of course for imaging... and joysick control of the website.   So
that is the stack we would be chosing.

- cherrypy code seems cleaner... as it's just python objects.

class MySite(object):
def index(self):
return "hello world!"

def news(self, id=None):
if id is None:
return main_news()
else:
return specific_news(id)

index.exposed = True
news.exposed = True

This creates these urls by default:
/
/index
/news
/news/10
/news?id=10


- cherrypy has less code compared to django, and is changing less.

- django is usually run using apache modpython or mod_wsgi, or even with
cherrypy(or other wsgi server).  They don't recommend using the bundled
django webserver.  Whereas cherrypy is considered one of, if not the best
python web servers.  With cherrypy you use the same webserver for
development, and for production.

- you can run cherrypy inside a pygame application.  Cherrypy doesn't
control the main loop if you don't want it to.

- there are more wsgi components than there are pinax apps.  Also pinax apps
should theoretically be able to play with wsgi.  I'm pretty sure you can use
django apps as wsgi components now too.










On Sat, Apr 25, 2009 at 3:51 PM, Nicholas Dudfield wrote:

>
> > I do not know anything about cherrypy, so here're some relevant
> > questions for both frameworks:
> >
> > * How good is the integration of a wiki solution and maybe bug tracking
> >   system without implementing it ourselves?
> > * How good is the integration of other components, which might be
> >   necessary in the future?
> > * How much effort has to be put into it to add new features? Is it just
> >   about adding/enabling a component or writing a whole bunch of code?
> > * What is the key difference between cherrypy (denoted as HTTP
> >   framework) and Django (web framework)?
> >
> >
> I have a little bit of experience with CherryPy and a tiny tiny bit of
> experience with Django. Here is my 2.0 cents.
>
> A while back I read a considerable amount about python frameworks before
> choosing CherryPy
>
> I say I chose CherryPy but that wasn't really the case. That choice was
> made for
> me. I did however choose further components to extend CherryPy with after
> becoming frustrated with `raw` CherryPy and a `raw` DB2 api.
>
> Making pages by concatenating strings is horrible and very resistant to
> change.
> You really want a templating system of some sort where you can integrate
> designers changes nicely or have them do it themselves (concurrently)
>
> You also want to be able to apply any special features your editor has for
> editing html.  Even PHP is better in this respect than `raw` CherryPy for
> anything beyond a `Hello World` toy site.
>
> Enter overwhelming array of choices.  Then you have to find a way of
> integrating
> the templating system with CherryPy.
>
> You'll find you want an ORM/query builder soon enough as writing your own
> (again
> using string building, you just want a small simple one) proves to be
> distracting. Any time you want a feature requiring something beyond your
> home-
> baked lib you have to code something up and write tests for it.
>
> Form handling? Do you want to write a form validation library? No? Spend
> some
> time searching for a good one *with a future*. Pagination? Email? I
> literally
> copy/pasted then modified the code from Django for the latter two.
>
> In short, you end up writing an ad-hoc glue framework on top of CherryPy.
> With
> just one person working on it, you can get away without writing a heap of
> tests
> and documentation. With multiple people working on it you'd really need to
> to
> make sure everyone is on the same page.
>
> Choosing CherryPy won't just be a matter of choosing it and running with
> it,
> it'll also be a matter of choosing more components, how to integrate them
> and
> documenting it.
>
> An advantage of doing it this way, not to be understated, is that you'll
> learn
> how to use those components individually and can apply them elsewhere.
>

Re: [pygame] PyGame Website Rewrite

[Nicholas Dudfield]

> I do not know anything about cherrypy, so here're some relevant
> questions for both frameworks:
>
> * How good is the integration of a wiki solution and maybe bug tracking
>   system without implementing it ourselves?
> * How good is the integration of other components, which might be
>   necessary in the future?
> * How much effort has to be put into it to add new features? Is it just
>   about adding/enabling a component or writing a whole bunch of code?
> * What is the key difference between cherrypy (denoted as HTTP
>   framework) and Django (web framework)?
>
>   


I have a little bit of experience with CherryPy and a tiny tiny bit of
experience with Django. Here is my 2.0 cents.

A while back I read a considerable amount about python frameworks before
choosing CherryPy

I say I chose CherryPy but that wasn't really the case. That choice was 
made for

me. I did however choose further components to extend CherryPy with after
becoming frustrated with `raw` CherryPy and a `raw` DB2 api.

Making pages by concatenating strings is horrible and very resistant to 
change.

You really want a templating system of some sort where you can integrate
designers changes nicely or have them do it themselves (concurrently)

You also want to be able to apply any special features your editor has for
editing html.  Even PHP is better in this respect than `raw` CherryPy for
anything beyond a `Hello World` toy site.

Enter overwhelming array of choices.  Then you have to find a way of 
integrating

the templating system with CherryPy.

You'll find you want an ORM/query builder soon enough as writing your 
own (again

using string building, you just want a small simple one) proves to be
distracting. Any time you want a feature requiring something beyond your 
home-

baked lib you have to code something up and write tests for it.

Form handling? Do you want to write a form validation library? No? Spend 
some
time searching for a good one *with a future*. Pagination? Email? I 
literally

copy/pasted then modified the code from Django for the latter two.

In short, you end up writing an ad-hoc glue framework on top of 
CherryPy. With
just one person working on it, you can get away without writing a heap 
of tests
and documentation. With multiple people working on it you'd really need 
to to

make sure everyone is on the same page.

Choosing CherryPy won't just be a matter of choosing it and running with it,
it'll also be a matter of choosing more components, how to integrate 
them and

documenting it.

An advantage of doing it this way, not to be understated, is that you'll 
learn

how to use those components individually and can apply them elsewhere.

From what I have read, each of the components in the Django stack have 
superior

respective stand alone alternatives.

eg Django ORM is almost univerally agreed upon to be inferior to SQLAlchemy

Peronally I have used this stack for a few sites:

   Request/Response/Server:  CherryPy
   ORM + Query Generator:SQLAlchemy
   Form Handling:FormEncode
   Templating:   Genshi
   Image Manipulation:   PIL

If I needed to learn TurboGears 2 or Pylons for some reason then I'd already
know many of the pieces. SQLAlchemy, FormEncode, Genshi.

If I need to use database access for anything then SQLAlchemy is very 
useful.
You can introspect existing databases easily and then just define the 
relations
with a few lines of code.  ( sqlalchemy.ext.sqlsoup ) If you define your 
schema
in python then you can automatically build the tables to whatever 
database you

like. SQLLite is useful for in memory test databases.

If I wanted to for some reason create dynamic and perfectly valid xhtml 
based
documents( say for converting to pdf format with Prince XML) then Genshi 
would
be hanging at my toolbelt. If I want to make a TRAC plugin I know how to 
use its

templating language. (The main TRAC developer also designed Genshi )

CherryPy itself has a Tool system for integrating third party components 
and for
abstracting code into reusable `filters`. Builtin Tools include unicode 
codecs,
gzip encoding, json encoding, header modifiers and the like. It has 
quite a nice
configuration framework supporting multiple deployment environments and 
allows

you to target filters right down to the exact page handler. It is a great
foundation to build upon with many points of extensibility. Pure WSGI (which
CherryPy fully supports) is less granular as far as `middleware`.

However you *will* end up having to create a framework, whether it be
consciously written or it just evolves naturally from factoring out 
duplicate
code. Needless to say, the first attempts will be pretty horrible. This, 
on top

of writing the actual site.

The potential advantage to Django is that you are walking a well 
travelled road

and it is well documented. And as it's a full stack framework all the
documentation is in one place, likewise with the `community`.

The #django irc channel almost riv

Re: [pygame] PyGame Website Rewrite

[Marcus von Appen]

On, Fri Apr 24, 2009, Rene Dudfield wrote:

> On Fri, Apr 24, 2009 at 10:06 PM,  wrote:
> 
> > René Dudfield :

[...]
> >>
> >> All the old stuff needs to be written at some point... because we need to
> >> keep all the old urls around (including feeds).  Also it's easier for
> >> people
> >>
> >
> > Is there a way to have some easy to manage URL rewriting/forwarding in
> > Django? That way we could let existing URLS resolve to the new stuff (e.g.
> > place the currently static html sites into the DB and link to them).
> >
> 
> Almost all web toolkits have decent url schemes, and rewriters.  It can also
> be done at the apache, and wsgi levels too.  The current website has a
> pretty good system... where it uses a database of rewrite rules editable
> through the web in the management system... but we can easily use
> mod_rewrite or whatever we need.
> 
> 
> I don't think we have agreed on Django specifically yet.  At least pymike,
> and I have suggested using cherrypy.  Also I know Nicholas has made the last
> few websites he worked on with cherrypy.
> 
> So we should decide this based on what the contributors to the website feel
> is best, and also the people who will maintain it.

I do not know anything about cherrypy, so here're some relevant
questions for both frameworks:

* How good is the integration of a wiki solution and maybe bug tracking
  system without implementing it ourselves?
* How good is the integration of other components, which might be
  necessary in the future?
* How much effort has to be put into it to add new features? Is it just
  about adding/enabling a component or writing a whole bunch of code?
* What is the key difference between cherrypy (denoted as HTTP
  framework) and Django (web framework)? 

> It can be easy to take the existing database and just use that.  This is
> quite easy to do with things like sqlalchemy and the like.

Absolutely no, I'd say. Did you put a look at its contents recently? ;-)
It'd be better to go with a new, clean database (and structure) and
write a set of SQL scripts to migrate the necessary data instead of
taking over anything.

Regards
Marcus


pgpUWcuomRsTX.pgp
Description: PGP signature

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

Couldn't the color scheme be user configurable? Allow the user choose 
among several options then track the choice with a cookie.


René Dudfield wrote:

Hellos,


On Fri, Apr 24, 2009 at 10:06 PM, > wrote:


The current one is already around and was widely tested. Or do I miss
something here?



Yeah, that can be used for lots of things... but not all.  So as to 
test things without messing up the main website... eg adding projects, 
wiki pages, news etc.  Maybe we don't really need to do this... and 
can just look at the code mostly.

Re: [pygame] PyGame Website Rewrite

[René Dudfield]

Hellos,


On Fri, Apr 24, 2009 at 10:06 PM,  wrote:

> René Dudfield :
>
>  hi,
>>
>> very awesome of you to go ahead with this...
>>
>> I read through your website... and it's got some good ideas...
>>
>> It'll be cool if we can make pygame one of the best sites around in the
>> python scene again... the current one is from around 2005... and has been
>> really good so far.
>>
>
> Well, the colours started to hit some nerves for me, so it might be better
> to go with some pastel colour palette for the new one :-).
>

yeah, perhaps.  We should probably have the graphical design as a separate
step.  So we can choose the best design made available.



>
>
>  Rewriting the current functionality in python first could be a good way to
>> go.  Once the current site is replicated, then move on to other stuff.
>>
>> All the old stuff needs to be written at some point... because we need to
>> keep all the old urls around (including feeds).  Also it's easier for
>> people
>>
>
> Is there a way to have some easy to manage URL rewriting/forwarding in
> Django? That way we could let existing URLS resolve to the new stuff (e.g.
> place the currently static html sites into the DB and link to them).
>

Almost all web toolkits have decent url schemes, and rewriters.  It can also
be done at the apache, and wsgi levels too.  The current website has a
pretty good system... where it uses a database of rewrite rules editable
through the web in the management system... but we can easily use
mod_rewrite or whatever we need.


I don't think we have agreed on Django specifically yet.  At least pymike,
and I have suggested using cherrypy.  Also I know Nicholas has made the last
few websites he worked on with cherrypy.

So we should decide this based on what the contributors to the website feel
is best, and also the people who will maintain it.






>
>  to work towards something that exists, rather than working towards a new
>> design.
>>
>
> A new design is necessary in my opinion. Colours, overall style, etc.
> The functionality though needs to stay the same (with improvements all over
> the place).
>

Sure, but that can happen after the current one is updated.  It's much
easier to make design as a separate stage.

So when reimplementing it we have the current website as a reference.  With
a new graphical design coming afterwards(or designed separately in
parallel).



>
>
>> First steps are to agree on a way forward... but if we go with remaking
>> the
>> existing site... we could follow this path:
>>
>> - prepare html/php/sql from old site.
>> - get old site running outside of the main pygame.org so people can test
>> it
>> easily.
>>
>
> The current one is already around and was widely tested. Or do I miss
> something here?
>


Yeah, that can be used for lots of things... but not all.  So as to test
things without messing up the main website... eg adding projects, wiki
pages, news etc.  Maybe we don't really need to do this... and can just look
at the code mostly.





>
>
>  - decide on which tools we are to use.  The main ones from people
>> interested
>> seem to be a django, or a cherrypy based site.
>> - start writing the models for the various tables, and data types in
>> existing site (eg, project, user, wiki page, etc).
>> - collect a list of existing urls.
>> - collect a list of existing functionality.
>> - collect a list of html/php pages to convert to templates.
>> - start working on list of functionality, and templates until it is
>> complete.
>>
>
> Sounds good to me. Though I'd go with the existing functionality first. The
> existing URLs and such are things to be considered for a final migration.
> Thus I would move this to the end:
>
> - put site up for people to test on a test domain eg test.pygame.org
> - work out migration plan:
>  - migrate projects and static content
>  - add functionality for eixsting URL handling
> - replace existing website on pygame.org, and make sure it works ok.
> - END.  then can work on adding new stuff.
>
> Otherwise it might easily happen to limit the new system in some areas due
> to
> the existing structure.
>
> Working out the migration can happen in parallel to the test phase. Letting
> people test is nothing, which should keep you on a 24/7 work load, so while
> anyone plays around with it, you can work on the necessary conversion
> system.
>

Yeah good point.

We will need to make sure the existing data can be put into the new website
at some point.

It can be easy to take the existing database and just use that.  This is
quite easy to do with things like sqlalchemy and the like.

So to decide which way we go, we should study the database structure to see
if it is ok.

Migrating the data is probably easiest if we use the existing database
directly.

The wiki code is mostly html, so isn't that hard to convert.






>
>
>  Also, is it possible to do this at google code instead?
>>http://code.google.com/p/pygame/
>>
>
> Sounds reasonable - google already has the whole 

Re: [pygame] PyGame Website Rewrite

[René Dudfield]

Hello,


On Fri, Apr 24, 2009 at 9:56 PM, jug  wrote:

> Hi,
>
> Analyzing  the current page in detail  is a good aspect to exchange
> the site without any problems. Do we need to run and modify the current
> page or is enough to read the code? Then you could send it to me and I'll
> upload it to the page (I think we don't need it in SVN, do we?).
>

yeah, you're right.  I think reading the current code is likely good enough.

Phil sent me a tar.gz with the website code... I have to finish going
through it to make sure there's no passwords, or peoples private information
in there.  Then I'll upload it soonest so you can have a look through it.

Marcus, when I'm done looking through it, can I send it to you to have a
quick double check for private info?

I'll have to do the same with the database data... get rid of email
addresses etc before upload.



>
> Sure, we could do that at google code but first I think, Tracs better (and
> looks
> nicer) for developing with the community and then we could run the new
> website
> from SVM there so everyone can always have a look at the latest version and
> test it.
>
> And you normally don't get an confirmation email. Just register and login.
>
> Regards
> Jug
>


Sorry, I think we're going to have to go with the google code website.
Because it's got all the nice account management, which a lot of people have
accounts with already... and it kind of seems safer hosted there.  As a
bonus though, you won't need to administer it.

I have added these people to the http://code.google.com/p/pygame/
jug, pymike, marcus, nicholas, orcun, ian

Just with your google account email address on this mailing list... if you
want to use another email address please send it over.

If anyone else wants to help with the website, please send me your google
account email address off the mailing list to my email address directly (you
can use non-google emails for your google account).

cheers,

Re: [pygame] PyGame Website Rewrite

[jug]

Have a look at http://pygameweb.no-ip.org/trac/wiki/Concept
Most of your points are already listed there. Add new ones so
we get an overview.

Jug

Re: [pygame] PyGame Website Rewrite

[Peter Gebauer]

Hello!

The two main priorities, imho, would be
1) documentation up to date with code
2) a wiki for additional documentation, examples, build instructions
   on various platforms, etc.

The project content could be easily transfered to wiki too. It might not
be better than a full database interface, but it's sufficient and easy
to maintain.
Also, there are already api doc generators for Python and good wiki's, so
no extra code would be written, only a build script for automating the process.

As a bonus, if we can generate API docs for specific versions that would be a
huge help.

/Peter

On 2009-04-21 (Tue) 22:38, jug wrote:
> Hello,
>
> Even if it was not selected as a project for GSoC, I would like to do  
> the pygame website rewrite.
> Like the other applicants, I'd do that with Django. Now that there can  
> not only be one student/participant,
> it would be cool to work together and combine forces.
>
> Since I applied for GSoC, I've already made a small concept. Merging  
> multiple implementing-/design ideas
> may become difficult, but before I go into detail just say me if you are  
> interested.
>
> Regards
> Jug

Re: [pygame] PyGame Website Rewrite

[mva]

René Dudfield :


hi,

very awesome of you to go ahead with this...

I read through your website... and it's got some good ideas...

It'll be cool if we can make pygame one of the best sites around in the
python scene again... the current one is from around 2005... and has been
really good so far.


Well, the colours started to hit some nerves for me, so it might be better
to go with some pastel colour palette for the new one :-).


Rewriting the current functionality in python first could be a good way to
go.  Once the current site is replicated, then move on to other stuff.

All the old stuff needs to be written at some point... because we need to
keep all the old urls around (including feeds).  Also it's easier for people


Is there a way to have some easy to manage URL rewriting/forwarding in
Django? That way we could let existing URLS resolve to the new stuff (e.g.
place the currently static html sites into the DB and link to them).


to work towards something that exists, rather than working towards a new
design.


A new design is necessary in my opinion. Colours, overall style, etc.
The functionality though needs to stay the same (with improvements all over
the place).


Remember, the main focus of the website should be peoples projects...
especially updated projects.  With all the other stuff coming after that.


Seconded.



First steps are to agree on a way forward... but if we go with remaking the
existing site... we could follow this path:

- prepare html/php/sql from old site.
- get old site running outside of the main pygame.org so people can test it
easily.


The current one is already around and was widely tested. Or do I miss
something here?


- decide on which tools we are to use.  The main ones from people interested
seem to be a django, or a cherrypy based site.
- start writing the models for the various tables, and data types in
existing site (eg, project, user, wiki page, etc).
- collect a list of existing urls.
- collect a list of existing functionality.
- collect a list of html/php pages to convert to templates.
- start working on list of functionality, and templates until it is
complete.


Sounds good to me. Though I'd go with the existing functionality first. The
existing URLs and such are things to be considered for a final migration.
Thus I would move this to the end:

- put site up for people to test on a test domain eg test.pygame.org
- work out migration plan:
  - migrate projects and static content
  - add functionality for eixsting URL handling
- replace existing website on pygame.org, and make sure it works ok.
- END.  then can work on adding new stuff.

Otherwise it might easily happen to limit the new system in some areas due to
the existing structure.

Working out the migration can happen in parallel to the test phase. Letting
people test is nothing, which should keep you on a 24/7 work load, so while
anyone plays around with it, you can work on the necessary conversion system.


Also, is it possible to do this at google code instead?
http://code.google.com/p/pygame/


Sounds reasonable - google already has the whole functionality for the  
project,

Julian currently hosts privately. It might be good to use google's wiki there
and a seperate website SVN branch. Especially since the final system could be
adopted by other community-driven projects.

Regards
Marcus

Re: [pygame] PyGame Website Rewrite

[jug]

Hi,

Analyzing  the current page in detail  is a good aspect to exchange
the site without any problems. Do we need to run and modify the current
page or is enough to read the code? Then you could send it to me and I'll
upload it to the page (I think we don't need it in SVN, do we?).

Sure, we could do that at google code but first I think, Tracs better 
(and looks
nicer) for developing with the community and then we could run the new 
website
from SVM there so everyone can always have a look at the latest version 
and test it.


And you normally don't get an confirmation email. Just register and login.

Regards
Jug

Re: [pygame] PyGame Website Rewrite

[René Dudfield]

hi,

very awesome of you to go ahead with this...

I read through your website... and it's got some good ideas...

It'll be cool if we can make pygame one of the best sites around in the
python scene again... the current one is from around 2005... and has been
really good so far.




Rewriting the current functionality in python first could be a good way to
go.  Once the current site is replicated, then move on to other stuff.

All the old stuff needs to be written at some point... because we need to
keep all the old urls around (including feeds).  Also it's easier for people
to work towards something that exists, rather than working towards a new
design.

Another benefit of remaking the existing website will be to understand the
features of the current site.


Remember, the main focus of the website should be peoples projects...
especially updated projects.  With all the other stuff coming after that.


First steps are to agree on a way forward... but if we go with remaking the
existing site... we could follow this path:

- prepare html/php/sql from old site.
- get old site running outside of the main pygame.org so people can test it
easily.
- decide on which tools we are to use.  The main ones from people interested
seem to be a django, or a cherrypy based site.
- start writing the models for the various tables, and data types in
existing site (eg, project, user, wiki page, etc).
- collect a list of existing urls.
- collect a list of existing functionality.
- collect a list of html/php pages to convert to templates.
- start working on list of functionality, and templates until it is
complete.
- put site up for people to test on a test domain eg test.pygame.org
- replace existing website on pygame.org, and make sure it works ok.
- END.  then can work on adding new stuff.


We can even make some basic functional tests to start with based on the
output of existing urls.  eg, grab the html from a wiki page from the
existing site, and then compare it to our new website.




Also, is it possible to do this at google code instead?
http://code.google.com/p/pygame/


What does everyone think of this?






cheers,



On Fri, Apr 24, 2009 at 4:35 AM, jug  wrote:

> Hello,
>
> to organize the development process, I've set up a SVN-repo and a small
> Trac at http://pygameweb.no-ip.org/trac/
>
> You'll find there a first concept and you can take part in developing
> it by adding your ideas. Some of the point are completely to work out,
> so just have a look. If you have a complete concept for one of the
> points (eg the design) create a new wiki page and add a link.
>
> If you would like to participate in developing, add yourself to the list
> on the start page and provide some information like I did.
>
> I've done the setup on the quick so if there are any problems with Trac
> or you need more rights, please email me.
>
> Regards,
> Jug
>

Re: [pygame] PyGame Website Rewrite

[jug]

Hello,

to organize the development process, I've set up a SVN-repo and a small
Trac at http://pygameweb.no-ip.org/trac/

You'll find there a first concept and you can take part in developing
it by adding your ideas. Some of the point are completely to work out,
so just have a look. If you have a complete concept for one of the
points (eg the design) create a new wiki page and add a link.

If you would like to participate in developing, add yourself to the list
on the start page and provide some information like I did.

I've done the setup on the quick so if there are any problems with Trac
or you need more rights, please email me.

Regards,
Jug

Re: [pygame] PyGame Website Rewrite

[pymike]

LOL, you nailed it right on the head.

On Wed, Apr 22, 2009 at 3:14 PM, Devon Scott-Tunkin
wrote:

>
> I'd like to help on the graphics side, the current site kind of looks like
> the python threw up all over the place.
>
> --- On Tue, 4/21/09, jug  wrote:
>
> > From: jug 
> > Subject: [pygame] PyGame Website Rewrite
> > To: pygame-users@seul.org
> > Date: Tuesday, April 21, 2009, 3:38 PM
> > Hello,
> >
> > Even if it was not selected as a project for GSoC, I would
> > like to do the pygame website rewrite.
> > Like the other applicants, I'd do that with Django. Now
> > that there can not only be one student/participant,
> > it would be cool to work together and combine forces.
> >
> > Since I applied for GSoC, I've already made a small
> > concept. Merging multiple implementing-/design ideas
> > may become difficult, but before I go into detail just say
> > me if you are interested.
> >
> > Regards
> > Jug
> >
>
>
>
>


-- 
- pymike

Re: [pygame] PyGame Website Rewrite

[Devon Scott-Tunkin]

I'd like to help on the graphics side, the current site kind of looks like the 
python threw up all over the place.

--- On Tue, 4/21/09, jug  wrote:

> From: jug 
> Subject: [pygame] PyGame Website Rewrite
> To: pygame-users@seul.org
> Date: Tuesday, April 21, 2009, 3:38 PM
> Hello,
> 
> Even if it was not selected as a project for GSoC, I would
> like to do the pygame website rewrite.
> Like the other applicants, I'd do that with Django. Now
> that there can not only be one student/participant,
> it would be cool to work together and combine forces.
> 
> Since I applied for GSoC, I've already made a small
> concept. Merging multiple implementing-/design ideas
> may become difficult, but before I go into detail just say
> me if you are interested.
> 
> Regards
> Jug
> 


  

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

The on-site documentation isn't automatically updated. Though it would 
be nice, it has become a lesser priority since the documentation is now 
bundled with the Pygame installer. For Python 1.9 just go into 
site-packages/pygame/docs to find them.


Lenard

Ian Mallett wrote:
I don't know, but I think so.  You have to click on some of the 
modules to get the correct toolbar on top, though. 

Re: [pygame] PyGame Website Rewrite

[Ian Mallett]

I don't know, but I think so.  You have to click on some of the modules to
get the correct toolbar on top, though.

Re: [pygame] PyGame Website Rewrite

[orcun avsar]

Is the current documentation dynamic through the current release?

2009/4/22 Ian Mallett 

> for example, http://www.pygame.org/docs/ does not link to pygame.color,
> among other modules
> Ian
>

Re: [pygame] PyGame Website Rewrite

[Ian Mallett]

Hi,
Certainly revisions are in order.  As a personal opinion, I like the general
layout/theme as is--but things like the documentation are out-of-date and
faulty (for example, http://www.pygame.org/docs/ does not link to
pygame.color, among other modules).  A few projects have been in the
"spotlight" on the main page for months, etc.
Ian

Re: [pygame] PyGame Website Rewrite

[el lauwer]

Hoi,

Tobad that the rewrite of the pygame website wasn't accepted as a GSUC  
project. But I think it would be a good idea to rewrite the site  
anyway, since the current site is a bit outdated. Maybe someone should  
put up a project page (wiki?).


Here are some random ideas:
	* I really like the django site, since the code is available under  
GPL we can base our site on that consept.

   code: http://code.djangoproject.com/browser/djangoproject.com
	* I think Trac would be usefull replacement for the current wiki and  
viewcvs, maybe in combination with git?

   http://nanosleep.org/proj/trac-git-plugin/
	* A better separation between documentation, news, projects and  
development.


Grtz

On 21-apr-09, at 22:38, jug wrote:


Hello,

Even if it was not selected as a project for GSoC, I would like to  
do the pygame website rewrite.
Like the other applicants, I'd do that with Django. Now that there  
can not only be one student/participant,

it would be cool to work together and combine forces.

Since I applied for GSoC, I've already made a small concept. Merging  
multiple implementing-/design ideas
may become difficult, but before I go into detail just say me if you  
are interested.


Regards
Jug

Re: [pygame] PyGame Website Rewrite

[orcun avsar]

I had applied to same project too.  I was thinking same idea it can be good
to work with a team. I'd like to join.

2009/4/21 jug 

> Hello,
>
> Even if it was not selected as a project for GSoC, I would like to do the
> pygame website rewrite.
> Like the other applicants, I'd do that with Django. Now that there can not
> only be one student/participant,
> it would be cool to work together and combine forces.
>
> Since I applied for GSoC, I've already made a small concept. Merging
> multiple implementing-/design ideas
> may become difficult, but before I go into detail just say me if you are
> interested.
>
> Regards
> Jug
>