i am glad to see that there are other people who feel that we should not use github. Lateral thinking is good most times. While we are at it I would like to suggest that we look at the Pygame documentation and re write it for people who are learning from scratch. There are a lot of places that it can elaborate a bit more with simple examples.
On Sat, Dec 24, 2016 at 6:08 AM, Miriam English <m...@miriam-english.org> wrote: > It's a pity you didn't read more than the first paragraph of my post, > Daniel. I understand you getting impatient, and I know it looks like I'm > trying to burst your bubble, but I'm not. I'm urging caution. I've seen too > many projects come undone by charging forward without care. > > - Miriam > > Daniel Foerster wrote: > >> We are proposing to use github because it gives us both git source >> control for versioning, free hosting, and a nice way to control >> contribution to the repository. There aren't "additional complications" of >> github, but rather desired features. >> >> — Daniel >> >> On 12/23/2016 04:44 PM, Miriam English wrote: >> >>> Hi Thomas, >>> >>> Those maintainers who have access to their part of the ibiblio site and >>> to sourceforge projects can update them as often as they want. No matter >>> what site you use it seems to me that there will still only be a small core >>> of people with access, so the additional complications of github seem to me >>> to be rather wasted. >>> >>> Do I understand it correctly? You are proposing to use github, something >>> designed to easily branch updates to software, purely to host webpages? It >>> seems a little like getting a lamborghini purely to do the weekly grocery >>> shopping. Github is a new, cool thing, and might look like it is the >>> solution to everything, but is it? (I notice there seems to be some >>> confusion here -- some are saying everything should go on github, others >>> seem to be insisting only the webpages.) >>> >>> Please note I'm not actually arguing against github. I know it sounds >>> like I am, but I'm not. I'm cautioning that humans tend to get an idea >>> fixed in their minds and we push for that regardless of its suitability. We >>> get trapped in a mindset. I just want to ensure that doesn't screw the >>> future pygame site by making the wrong choice early on when it could be >>> changed. >>> >>> I'll throw in another idea: we could all put in a couple of dollars and >>> buy a website which we could have *total* control over. That would give any >>> degree of access or restriction desired, and the ability to host static >>> pages until maybe we came up with a really easy way to do dynamic pages >>> (personally, I prefer static pages). We could have any amount of anti-spam >>> measure we wished. Again, I'm not actually pushing this idea; it is just >>> another suggestion. >>> >>> And another: someone on this list is sure to be associated with a >>> university. They often make available part of their site for worthy >>> projects. That would allow a high degree of degree of access and autonomy, >>> but would be free. >>> >>> I'm sure there are other possibilities. >>> >>> Cheers, >>> >>> - Miriam >>> >>> >>> Thomas Kluyver wrote: >>> >>>> Hi Miriam, >>>> >>>> Looking at ibiblio.org <http://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 <http://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 >>>> <mailto:m...@miriam-english.org>> wrote: >>>> >>>> The two repositories I mentioned, ibiblio.org <http://ibiblio.org> >>>> and archive.org <http://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/ >>>> <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 >>>> <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> >>>> <mailto: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> >>>> <http://archive.org> and >>>> ibiblio.org <http://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/ >>>> <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>> >>>> <mailto: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> >>>> <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> >>>> <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/>> >>>> <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>> >>>> <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>>> >>>> <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 <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>>> >>>> <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 <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>>> >>>> <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 >>>> <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>>> >>>> <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 <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>>> >>>> <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 <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>> >>>> <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>> >>>> <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 >>>> <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" > > -- Kalasuri Diliup Gabadamudalige https://dahamgatalu.wordpress.com/ http://soft.diliupg.com/ http://www.diliupg.com ********************************************************************************************** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **********************************************************************************************
