Miriam, I think you're missing the issue here. Almost all of the content would be put in GitHub (Thomas even suggests that everything go there). Using ibiblio.org/archive.org doesn't help us any as far as the game showcase goes, which is the main matter of debate; you're still trying to find a good user-friendly way to submit content without opening the door wide open for abuse.
On Thu, Dec 22, 2016 at 3:02 PM, Miriam English <m...@miriam-english.org> wrote: > I don't see the point of using github for the web pages and keeping the > content elsewhere. I don't have a lot of experience using github (I find it > a pain actually). Github is intended as a versioning system. That has no > utility for a pygame repository, as far as I can see -- or at least no > advantage over an ordinary repository built purely with that purpose in > mind. > > Wouldn't it be simpler to keep the whole thing in a repository? I > mentioned 2 earlier: archive.org and ibiblio.org, both of which are free > and very secure. > > Cheers, > > - Miriam > > > Thomas Kluyver wrote: > >> Thanks everyone for your input. In the interests of making progress, I'd >> like to propose: >> >> - The informational site will be hosted on Github pages; I've used this >> for a number of websites before, it's reliable, we can point an external >> domain to it, and I imagine that most of the likely contributors have >> Github accounts already. >> - The pages will be generated by a Python static site generator. There >> doesn't seem to be a strong feeling between Sphinx/Nikola/Pelican, so it >> will likely depend on who is most excited to start building it. >> - The game feed will also be generated from content in Github, so /at >> first/ developers will need to submit a PR to add a game. Once that's >> working, we can build a simpler submission interface on >> Heroku/Appengine/similar which can push content to Github. Ideally the data >> will be in a format which would could move elsewhere later if necessary. >> >> I like the concept of drawing the game feed from an external source, but >> I don't think any of the sources proposed match what we want closely enough. >> >> Does anybody object to any of those proposals? >> >> Thanks, >> Thomas >> >> On 18 December 2016 at 20:18, Miriam English <m...@miriam-english.org >> <mailto:m...@miriam-english.org>> wrote: >> >> http://ibiblio.org is an enormous, free repository that also lets >> you have static webpages. Many of the Linux distros are hosted >> from there as well as much else too. I don't know how you'd set up >> a comments system there. It may be possible. >> >> http://archive.org is another gigantic free repository. They >> already have a comments system built into their pages. I don't >> know how it works. It might be worth checking out. >> >> Both these organisations are free and are aimed at helping make >> content available to the community which might otherwise be lost. >> You have complete control over the look of webpages at ibiblio.org >> <http://ibiblio.org> because you simply upload static pages. >> >> I don't know how much control over the look archive.org >> <http://archive.org> provides because everything is dynamically >> >> served from xml data, I think. It might be possible to add static >> content, I don't know. >> >> But both are free, permanently available, and have excellent security. >> >> Cheers, >> >> - Miriam >> >> >> >> Peter Shinners wrote: >> >> Gitlab also has great static site support for free, and you >> can use custom domains. They also make it easy to run most >> static generation tools as a CI job. Although part of me >> thinks just pushing the static content is easiest. It sounds >> to me like there's a list of acceptable hosting choices that >> won't cost anything. >> >> Keeping the games list as a feed from other service sounds >> like it has the best chance of working. >> >> >> On 12/17/2016 10:51 PM, Lenard Lindstrom wrote: >> >> Bitbucket also has static web site support. I set one up >> for the Pygame docs awhile ago, but have not maintained it: >> >> http://pygame.bitbucket.org/docs/pygame/ >> <http://pygame.bitbucket.org/docs/pygame/> >> >> The repository is here: >> >> https://bitbucket.org/pygame/pygame.bitbucket.org >> <https://bitbucket.org/pygame/pygame.bitbucket.org> >> >> Lenard Lindstrom >> >> On 16-12-17 09:16 PM, Daniel Foerster wrote: >> >> You know, I suppose we could just use GitHub pages. >> >> On Dec 17, 2016 17:32, "Charles Cossé" >> <cco...@gmail.com <mailto:cco...@gmail.com> >> <mailto:cco...@gmail.com <mailto:cco...@gmail.com>>> >> wrote: >> >> >> >> On Sat, Dec 17, 2016 at 4:12 PM, Daniel Foerster >> <pydsig...@gmail.com <mailto:pydsig...@gmail.com> >> <mailto:pydsig...@gmail.com >> <mailto:pydsig...@gmail.com>>> wrote: >> >> Using S3/CloudFront is a lot cheaper than the >> EC2 setup you're >> imagining (and which a Django stack would >> require). >> >> >> >> I never said to use Amazon at all. Just use the >> current server, >> whatever it is (unless it's Amazon). >> >> On 12/17/2016 05:11 PM, Charles Cossé wrote: >> >> Yikes! who's gonna pay the Amazon bill? >> >> On Sat, Dec 17, 2016 at 4:09 PM, Paul >> Vincent Craven >> <p...@cravenfamily.com >> <mailto:p...@cravenfamily.com> >> <mailto:p...@cravenfamily.com >> <mailto:p...@cravenfamily.com>>> wrote: >> >> If most of the site is static, then I >> think Django would >> be overkill. The static portion of the >> site can easily be >> deployed via Amazon S3/CloudFront and >> then we'd not have >> to maintain a server. >> >> Paul Vincent Craven >> >> On Sat, Dec 17, 2016 at 5:00 PM, >> Charles Cossé >> <cco...@gmail.com <mailto:cco...@gmail.com> >> <mailto:cco...@gmail.com >> <mailto:cco...@gmail.com>>> wrote: >> >> >> On Sat, Dec 17, 2016 at 3:26 PM, >> Thomas Kluyver >> <tak...@gmail.com <mailto:tak...@gmail.com> >> <mailto:tak...@gmail.com >> >> <mailto:tak...@gmail.com>>> wrote: >> >> >> So far, I think the proposals >> for the static >> information part of the site >> are Nikola (a static >> site generator oriented around >> blogs) and Sphinx >> (oriented around docs). Both >> are written in >> Python. Does anyone want to >> make the case for any >> other system? >> >> >> Can Django factor-in there? I >> guess it would reside >> underneathe the other pkgs ... but >> might as well run >> Python through-and-through imho. >> >> >> >> >> >> -- >> Linkedin >> <https://www.linkedin.com/in/charles-cosse >> <https://www.linkedin.com/in/charles-cosse>> | >> E-Learning <http://www.asymptopia.org> >> >> >> >> >> >> >> -- >> Linkedin >> <https://www.linkedin.com/in/charles-cosse >> <https://www.linkedin.com/in/charles-cosse>> | E-Learning >> <http://www.asymptopia.org> >> >> >> >> >> >> >> >> >> -- There are two wolves and they're always fighting. >> One is darkness and despair. The other is light and hope. >> Which wolf wins? >> Whichever one you feed. >> -- Casey in Brad Bird's movie "Tomorrowland" >> >> >> > -- > There are two wolves and they're always fighting. > One is darkness and despair. The other is light and hope. > Which wolf wins? > Whichever one you feed. > -- Casey in Brad Bird's movie "Tomorrowland" > >
