Leif, thanks for your emails. It could be helpful if you have a proposal, that you put it forward.
I think you've definitely made your position, and your priorities clear about what we should do. However, so far I don't see a clear proposal from you with any support. Perhaps if there was one we'd have a better idea about what you are planning to do. And people could decide if your plan is something they want to do. However from what you've written, I don't feel that this proposal will fail to deliver 'modern' features you're after. You seem to have missed the part where we said a few times that new SDL2 features would be added. If there's people interested in adding the additional SDL2 APIs to this work, no one will stop them, and they will be supported. Additionally, it's been pointed out to you that several other python libraries exist which are based on OpenGL with textures. People can use them today. A few of those libraries are featured on the front page of the pygame website. Compatibility is important to me, and I think I've put my best case forward about how I think it will save us effort in development. Not to mention saving effort for the hundreds of thousands of people who are currently using pygame. I think compatibility is important to other developers because there are a few other implementations of the pygame API which aimed for compatibility. Additionally, I think it prudent we do a spike test on linux to see if things are actually going to be good enough, and I think we can decide to change approach if it turns out that compatibility is harder than expected after wider testing. Perhaps there is support for a new, from scratch pygame with modern features for real developers developing real games which breaks compatibility. To find out, a proposal for such would help. For the record, I think some of the things that you've mentioned are good ideas backed up by evidence, sound thinking, and fair criticism. Thank you for your contribution and passionate discussion. And to summarize some parts of the conversation so far, including the changes and clarifications to the original proposal: - You can actually build pygame from source now with SDL2. No need to wait 3 years. - SDL2 features, like textures can be supported with new APIs. New games can stick to those features if they prefer, or use an alternative library with no pygame compatibility. - Compatibility is important to at least some people. - I think it prudent we do a spike test on linux to see if things are actually going to be good enough, and I think we can decide to change approach if it turns out that compatibility is harder than expected. So far the unit tests pass, and there is no known theoretical reason why compatibility is not possible. Older versions of pygame will still be available by pip, and it's still possible for people to repackage pygame 1.9.3 on linux as pygame1 if absolutely needed - but I doubt it will be. - Some people are worried about compatibility wasting effort. Some would like compatibility if it's not going to take too much effort. There is concern compatibility would be hard to do. - Performance on raspberry pi and other educational boards is important to me(and others). And by releasing pygame+SDL2 for linux first, we can get there pretty quickly. - The no patches accepted slander is easily disproved by looking at the patches we accepted by many people. Some people on this list have even spent months of boring admin effort so that other people can get paid to work on pygame projects. - The SDL1 code is already there, and I don't think me or anyone else will be writing any SDL1 specific code. Probably almost zero. If the concerns about maintenance turn out to be true after we do the changes for linux first, we can change our minds. - Mobile support is important to people. I don't see this proposal blocking anyone working on mobile support, only making it easier. However, I personally think we have more basic concerns. For iOS we would still need to work out licensing. For iOS pygame_sdl2 is an option for people today. - Better tooling for distribution of apps should probably continue to happen outside of pygame. Likewise for other complicated things that don't need tight coupling. - New modules in Cython are a fine idea(we have one part already in Cython). Even though we actually get more contributions for C than the python or Cython parts so far. [Pyrex forever!] No one has objected to this. - Tom has made an offer to share/relicense pygame_sdl2 code, and would love to work with anyone on bringing pygame_sdl2 up to parity with pygame. May rename it something else. Not sure if he is interested in collaborating with the pygame+sdl2 patches I'm proposing, seems busy with full renpy schedule. But I'd be happy to use anything he has to offer in there. I'm not sure if the pygame in this proposal would be good enough for him to use, and I'd be interested in knowing what else we'd need to change to make it usable by Ren'Py. I claim that it would be usable for him with perhaps some work (excepting, iOS where the licensing situation would need to be complete first). pygame_sdl2 is probably the best path for anyone wanting to port their pygame game to iOS at the moment. - The steam stuff in pygame_sdl2 is probably of interest to anyone wanting to distribute their games for money. - I'm not sure the best path for android at the moment. I guess Tom probably knows this answer best? Perhaps something Kivy has made can be used. But I know people are still using pygame subset for android for older android mobiles. - If anyone else wants to make a separate proposal, and needs more time to write it, that's ok with me. But it would still be good to try and work through things in the week specified. The time is now to raise concerns, make suggestions, or ask for more time to make a proposal. The more input, encouragement and criticism now the better. But I don't want to rush anyone who wants time to think things through and write a serious alternative proposal. - One suggestion that perhaps MIT or apache license would be better than zlib. No one so far has opposed leaving the LGPL, but we haven't asked all of the copyright holders who might not pay attention to the list. Additionally no one has objected to this idea when it was brought up in previous years. - A few concerns about moving to github, but probably more support for the move. Not so much discussion yet though. No specific plan of how we could proceed on this or when has been made. If anyone has a strong objection to moving to github, or wants time to think about it more... please speak up? There are still some people on the bitbucket we haven't added to the github. That's the first step (I will try and find everyone, but please send me your nickname on there if I haven't already found you?). The build tools should be able to be moved easily. There is a pretty good import from bitbucket script provided by github. I've already started to move issues from the website that were on there. The open source pygame website is already on github, as are git mirrors of the pygame repo. Also the solarwolf game is on the pygame organization github. If I can't find everyone, or I don't hear from everyone who I haven't added from bitbucket to to the pygame github yet, I'll email them personally to ask. I'll leave the bitbucket there, but write a note in the README about the move, and on everywhere else I can (eg, in the issues etc). I'll email the maintainers (eg, debian) about the move. The main reason for the move is that most of the python community is there now, and that more people know git. cheers, On Tue, Mar 21, 2017 at 1:39 PM, Leif Theden <leif.the...@gmail.com> wrote: > I'll add, so that my comments don't seem too caustic, that the maintainers > have gotten more responsive recently. The "don't accept patches" comment > isn't as true as it used to be. > On Tue, Mar 21, 2017 at 7:27 AM Leif Theden <leif.the...@gmail.com> wrote: > >> At this rate, we can expect SDL 2 to work in 3 years...all in the name of >> compatibility? It doesn't help that Rene is also maintaining the webpage... >> he's got no time. Let's be realistic, there are very few people who have >> the will or ability to deal with the pygame code base; and with the >> maintainers past record of not accepting patches, this transition will be >> very slow. >> >> This dual library approach sounds like a nightmare to implement. Consider >> that you will effectively be writing code destined to be thrown out when >> SDL1 is no longer needed. You clearly must not value your own time, to be >> spending it on throw away shim code. There are significant differences in >> SDL 2 that you will be writing and maintaining adapter code for, like >> Leonard mentioned. Pygame isn't some mission critical piece of software. >> Let 1.9 be, and put all new patches into getting SDL2 working for 2.0, and >> let there be broken changes. Let someone else maintain 1.9, if they have a >> desire to maintain it. >> >> And putting priorities into the software rendering subsystem is harmful. >> The old tutorials and books are not useful, because no games or >> applications use software rendering. Students will still hit a performance >> wall because they are taught to use surfaces instead of textures and will >> just move onto another platform because "Python is slow". >> >> Python and pygame could rule the SBC educational market, but it is so >> slow on those platforms without hardware acceleration that it become >> frustrating to use. >> >> Students should be taught how textures work, where different memories >> reside, and that GPUs operate differently than a CPU. At this point I think >> everyone knows where I stand, so I'll just let it go, since my comments are >> not being taken seriously. >> On Tue, Mar 21, 2017 at 6:15 AM Thomas Kluyver <tak...@gmail.com> wrote: >> >> On 21 March 2017 at 10:48, René Dudfield <ren...@gmail.com> wrote: >> >> It sounds like you're still not convinced though. I can make the tree >> first, and we can see what it looks like more easily. If it turns out to be >> not such a good idea afterwards we can always remove sdl1 support. >> >> >> I'm not entirely convinced - maintaining compatibility with SDL 1 and 2 >> sounds like the sort of thing that *should* be easy, but could leave us >> with a lot of corner cases where one or the other doesn't work, and result >> in confusing issues when a game is tested on one and then unwittingly >> played on the other. >> >> But I don't know SDL well enough to understand how big the difference is, >> and the transition doesn't interest me enough to work on it myself. I'm >> satisfied that I've made my case, and you're evidently not convinced, so go >> ahead and do it as you've planned. >> >> The one detail I'd ask for before any SDL1/2 release is a Python API to >> get the SDL version number, if there isn't one already, so when people >> report issues there's an easy way for them to find out which SDL they're >> using. >> >> Thomas >> >>
