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,