Can't we just make it so only a few known-good users have access to merge
to master and then use pull requests for edits to the site from the
community? this is a common way to do it both for sites and otherwise -
Ionic does their tutorial websites this way.
The only real issue I would see is that you wouldn't really want a single
repo with binaries or even of source of all games submitted. That would
clutter up the repo for the website with essentially backend data edits.
I would suggest making a template repository for users to fork on GitHub
that would include an editable readme.md with a good starting framework.
They could update the readme to include descriptions of their games and
these could be pulled into a list.
Regarding static vs dynamic sites and games lists, we could preprocess the
games list into one big json file and then just implement the game list
view as an Angular application. That would allow
sorting/filtering/searching of content with no dynamic processing on the
server side whatsoever - just when a new project is accepted, that json
file would be updated to include the link and some tags about each game.
On Fri, Dec 23, 2016 at 12:49 PM, Thomas Kluyver <tak...@gmail.com> wrote:
> Hi Miriam,
>
> Looking at ibiblio.org, it's talking about an application process to host
> a 'collection' there ("A decision will be made and you will be notified.").
> This sounds rather controlled for a simple static site, and I'm concerned
> that it won't be as easy as we want to update the site and for multiple
> people to work on it. Clicking around the distros section, it looks like
> most distros host downloads there but have a website somewhere else (so
> far, Fat Dog is the only one I've found with web pages there). This
> suggests to me that it's not ideal for hosting a website.
>
> It's hard to put my finger on what's wrong with it, because clearly you
> *can* host static web pages there. But looking around the information pages
> and the Q&A site, I get a very strong feeling that hosting there would
> involve a lot of time and hassle that I don't want.
>
> Similarly for archive.org, I think it's intended as... well, an archive!
> That's valuable, but it's not the problem we're trying to solve.
>
> Github pages is a very convenient way to host a website, and to manage
> multiple people making changes to it. I know a lot of open source projects
> whose websites are hosted this way. It does require using git to update the
> site, and I'm sorry if that's difficult for you, but it's a system that
> works well for a lot of people. None of the arguments I've read so far
> provide a compelling reason *not* to host a site on Github, and the only
> option that I see as a reasonable alternative is Gitlab, which presumably
> works in a very similar way to Github.
>
> > Is it possible to have something that is safe, but easy for newbies to
> add games to a site?
>
> I think it is, if we accept that it just needs to be 'safe enough'.
> Automatically adding 'nofollow' on user provided links reduces its value to
> spammers a lot. I believe Google's recaptcha tool does a reasonable job of
> stopping bots. And if it's still not enough, we can authenticate users and
> require an admin to approve a user's first submission.
>
> Thomas
>
> On 23 December 2016 at 01:45, Miriam English <m...@miriam-english.org>
> wrote:
>
>> The two repositories I mentioned, ibiblio.org and archive.org (I'm sure
>> there are more) have, as far as I know, no limits on storage.
>>
>> Have a look, for instance at the amount stored for Puppy Linux at ibiblio:
>> http://distro.ibiblio.org/puppylinux/
>>
>> Each of those subdirectories you see relates to a different kind of Puppy.
>>
>> The packages directories contain programs specifically tailored for a
>> particular distribution of Puppy. The pet_packages-lucid directory alone
>> contains more than 10 Gigabytes of programs, and there are more than 30
>> Puppy distros with associated package collections.
>>
>> The puppy-528 directory contains a couple of ISO CD images for Puppy
>> Lucid 528. It also contains an explanatory webpage:
>> http://distro.ibiblio.org/puppylinux/puppy-5.2.8/release-Lucid-528.htm
>>
>> Most of the main distro directories contain such a page.
>>
>> There is lots more on ibiblio, as a quick wander around
>> http://distro.ibiblio.org/ will show.
>> They also have multiple mirrors around the world, so if one set of
>> servers has a problem others are available.
>>
>> Cheers,
>>
>> - Miriam
>>
>>
>> Charles Cossé wrote:
>>
>>> Hi,
>>>
>>> On Thu, Dec 22, 2016 at 2:02 PM, Miriam English <m...@miriam-english.org
>>> <mailto: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 <http://archive.org> and
>>> ibiblio.org <http://ibiblio.org>, both of which are free and very
>>>
>>> secure.
>>>
>>>
>>> I can say a little bit that might help until someone with more knowledge
>>> has time to reply ... With GitHub pages your website is "just another"
>>> repo. That's the main thing I wanted to point out. There are no storage
>>> limits, and I'm pretty sure that GitHub would be happy to help pygame
>>> accomodation-wise if pygame needed anything special (within reason). I
>>> also know that there is a 4 gigabyte file limit on GitHub. (I know this
>>> because I once wanted to host an 8G SD card image and had to get it down to
>>> 4G in order to be housed on GitHub).
>>>
>>> FWIW, I have also managed to run webapps on GitHub via GitHub pages.
>>> For example http://asymptopia.github.io/TuxMathScrabble-2015/.
>>>
>>> And, not trying to direct traffic to my site or anything, but here's my
>>> own site using GitHub pages: https://asymptopia.github.io/
>>>
>>> Best regards,
>>> Charles
>>>
>>> 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>
>>> <mailto: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>
>>> <http://ibiblio.org> because you simply upload static pages.
>>>
>>> I don't know how much control over the look archive.org
>>> <http://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/>
>>> <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>
>>> <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>>
>>> <mailto: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>>
>>> <mailto: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>>
>>> <mailto: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>>
>>> <mailto: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>>
>>> <mailto: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>
>>> <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>
>>> <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"
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Linkedin <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"
>>
>>
>
