I’m certain SDL will not be moving to GitHub or BitBucket. It is
self-hosted by the SDL project servers. Obviously if it were in git,
it could be easily mirrored to GitHub or anywhere else, but those
will only ever be mirrors.
JosephOn Tue, Dec 01, 2015 at 12:28:30PM +0330, Amir Ramezani wrote:
hello,
in my idea, github has many advantages than bitbucket and googlecode
(which is closing)
first of all, a developer pushes his changes to repository using git
then, i can get those changes without any concerns using SVN
(because of my eyesight problem, i can use SVN and tortoiseSVN easily
with my screen reader)
second, github is more accessible than bitbucket for vision impaired
users like me
third, github’s pages load very fast eaven with a slow internet (in my
country internet is slow)
forth, googlecode restricted some countries (du to sanctions)
but open source projects must be accessible to anyone in anyware in the world
i’m not saying that SDL should be gon into github or anything else!
i’ve said github became popular for these reasons that i’ve said
google code sanctioned some of the countries, bitbucket is
inaccessible for vision impaired users, but github does not have these
limitations
because of these, + many other features, github became very very
popular eaven popular than source forge
???-??-?? ?:?? GMT+??:??, T. Joseph Carter :> I’m certain SDL will not be moving to GitHub or BitBucket. It is
self-hosted by the SDL project servers. Obviously if it were in git,
it could be easily mirrored to GitHub or anywhere else, but those
will only ever be mirrors.
Joseph
On Tue, Dec 01, 2015 at 12:28:30PM +0330, Amir Ramezani wrote:
hello,
in my idea, github has many advantages than bitbucket and googlecode
(which is closing)
first of all, a developer pushes his changes to repository using git
then, i can get those changes without any concerns using SVN
(because of my eyesight problem, i can use SVN and tortoiseSVN easily
with my screen reader)
second, github is more accessible than bitbucket for vision impaired
users like me
third, github’s pages load very fast eaven with a slow internet (in my
country internet is slow)
forth, googlecode restricted some countries (du to sanctions)
but open source projects must be accessible to anyone in anyware in the
world
It doesnt work with OpenGL code, only with SDL code.
SDL_RenderReadPixels reports pixel colors a little wrong.
I use it like this:
SDL_RenderReadPixels(gv.renderer,&rect,SDL_PIXELFORMAT_RGB24,(void )pixel,804);
I give a solid color of (150,20,30) and it reports 147,20,27.
The thing is that it reports different colors some times like 148,20,25
or 152,20,28.
I use SDL_RenderReadPixels to know what I am clicking so I cannot go on
with my apps.
I would prefer it worked with my OpenGL code, did anyone try it, any
examples?
For #1, what kind of issue do you get when you try to use OpenGL? It works fine in the Simulator at least for me, and I believe other people have it working fine on real devices.
SDL?s code there is the same on both iOS and tVOS.
For #2, SDL requests an 8 bit (RGB 332) backbuffer by default, when creating any OpenGL or OpenGL ES context (including the one used by SDL_Render when it uses GL or GLES as a backend), unfortunately. SDL on iOS will try to use a 16 bit (RGB 565) backbuffer in that case, which will probably cause that kind of difference.
You can change that to a 24/32 bit backbuffer by calling SDL_GL_SetAttribute and specifying 8 bits each for SDL_GL_RED_SIZE, SDL_GL_GREEN_SIZE, SDL_GL_BLUE_SIZE, and optionally SDL_GL_ALPHA_SIZE, before creating the SDL window and renderer, when the renderer will use an OpenGL or OpenGL ES-based backend.> On Dec 3, 2015, at 7:34 AM, Giorgos Sarris wrote:
It doesnt work with OpenGL code, only with SDL code.
SDL_RenderReadPixels reports pixel colors a little wrong.
I use it like this: SDL_RenderReadPixels(gv.renderer,&rect,SDL_PIXELFORMAT_RGB24,(void )pixel,804);
I give a solid color of (150,20,30) and it reports 147,20,27.
The thing is that it reports different colors some times like 148,20,25 or 152,20,28.
I use SDL_RenderReadPixels to know what I am clicking so I cannot go on with my apps.
I would prefer it worked with my OpenGL code, did anyone try it, any examples?
Not to annoy the powers that be with this conversation again, but is there any chance GitHub or GitLab would be reconsidered? I read all the arguments not to make the switch, and from my perspective none of them are nearly as compelling as “everybody is used to working with this platform now, it’s huge, and for this one project you’re asking them to learn a new source control, code review and submission stack”.
It’s not a matter of guessing whether contributions from others will go up if you make the switch, it’s a certainty. There has been tons of documentation of this when projects moved to GitHub.
It’s also not an issue of “SDL is too big”, Python made the jump and saw major gains:
Most specifically, for PYTHON, a huge project that didn’t have a contribution problem:
the number of commit has increased by 190%
inserted lines of code has increased by 140%
number of unique contributors has increased by 1300%
number of returning contributors has increased by 900%
I raise this because as an extremely busy professional developer, I considered contributing something to SDL that would have helped me in a hobby project of mine. I saw that it had its own submission and repo process that I’d have to learn, and decided not to bother. I’m sure I’m not the only one.
Can we just let this rest already? This topic has been dead and buried for years!
Also:
The number of commits is an utterly meaningless measure of progress in a project, especially in a revisionism-embracing patch manager such as git. Corollary: git histories are always lies.
The number of contributions and contributors is not important. In fact, a high number of contributors is more likely be detrimental than helpful. The number of high quality, directly accepted contributions and their size is the more relevant measure.
I do find a reconsideration of that reasonable. After the time passed things (may) have changed and reasons valid before might not be anymore.
Example: Git is massively more popular than Hg (https://stackshare.io/stackups/git-vs-mercurial). So it’s more likely that people wanting to contribute to SDL are familiar with Git but not Hg
I used Hg ages before and still the GUI and web interface are worse than e.g. Github or Gitlab. Especially the integration of bug reports and merge/pull requests are really helpful.
If switching to Github for the sake of it being Github is the problem, then one can host its own Gitlab instance (free AFAIK) which is similar enough.
I’m not sure if I understand your reasoning Gregor about not re-evaluating…a technology was evaluated years ago, since then the already popular technology has skyrocketed to an absurdly popular technology, and has unquestionably become the de facto standard for open source development. It’s worth reconsidering whether the arguments for have gotten stronger on a regular basis, unless you believe people shouldn’t re-evaluate technology over time.
You can argue number of commits is meaningless using your argument, but the counter point was already in the statistics I posted: “inserted lines of code has increased by 140%”. It’s hard to argue that’s a bad thing when you have a good code review system in place, that just means more good code is making it into the repo.
I would also disagree heavily that ‘small’ commits/committers aren’t useful. The thing I would have committed was SDL2 package-info for CMake, so that developers who wanted to use CMake could use SDL2 much easier on all platforms (right now it requires manually installing something into CMake, as CMake is not accepting commits for individual packages anymore, they want it living inside the package).
Is that as useful as someone contributing to the core of SDL? Certainly not. But it’s nice someone on the core of SDL wouldn’t have to waste their time doing something like that. In aggregate small commits and lots of committers are a good thing, assuming there’s a good code review and testing process.
Look I’m an outsider here, this isn’t my project, I just wanted to raise the point again to the powers that be that this project is likely missing out on new contributors coming on board because of the current system. Less committers also likely means less users, which is generally perceived as a bad thing for a library.
Maybe the powers-that-be are OK with that.
How often does one have to say no on the internet until it is taken as a no? </troll>
Neither git nor Mercurial have changed in any significant way that suggests that a reevaluation is appropriate.
About contributions: Accepting (or even rejecting) contributions involves its own kind of overhead in the process (been there, done that). So small contributions are really inefficient. Also, a mature project like SDL cannot really be measured in terms like added lines of code. Most of what is going on is in the realm of careful tweaks and bugfixes.
Whether the cmake script was an enhancement or change for the sake of change is not easy to decide for me. It had a major ripple effect - between patch releases, even. But that is jot what this discussion is about.
Git aside - the attitude towards contributors seems way more troubling to me. I feel like I’m in a bizarro world with an open source developer insisting they don’t care about having more people committing/using their code. I’m having a hard time squaring your claims about small commits with anything else I know about software development. You are speaking with a very authoritative voice here on how software development should be done, and I have to say it doesn’t square with any professional software development I’ve witnessed in my 20 year career. The notion that small commits aren’t worth it because they’re too much overhead is mind boggling. Modern development practices dictate that you want small contributions as they’re easier to code review and when things break it’s easier to determine the source of failure.
As to the stance on occasional committers - occasional / first time committers often become long-term heavy committers, losing them up front means losing the chance of them becoming significant contributors – another weird stance. If disliking small commits / occasional committers (even of good code) is the stance of SDL, so be it, but it likely means when the current contributors move on, they won’t be replaced, and the project will die.
If your views aren’t that of the SDL project as a whole, it’s probably not good to speak with such an authoritative voice on the forums.
On that note, I’ve wasted enough time on this, I only even responded this time out of disbelief of what I was reading – best of luck going forward.
A few years back, I was living near Sam, and we got together to hang out one time and talk about SDL. At one point, I brought up a prominent missing feature (something to do with custom shaders, I think, but it’s been a while) and he said there’s no plan to bring it into SDL. I mentioned how other, competing frameworks were supporting this feature, and I brought up Zawinski’s Law, that all software expands and grows new features over time, and those which cannot so expand are replaced by ones which can, and Sam was basically like, “well, if that’s what happens then so be it.” He made it pretty clear that sticking to his vision of a limited scope for SDL was more important to him than either market share or doing things that developers using SDL might think would improve the product, if it didn’t fit the vision.
Considering how many games use SDL right now, (not to mention Valve the company behind Steam, Half-Life, Half-Life 2, Team Fortress 2, DOTA, (all of which use SDL if memory servers me correctly), employs the original author of SDL), I don’t see how SDL will be dying any time soon.
Here’s a question for you, can any of the devs of SDL control the GitHub servers directly? That’s the reason why they have their own server, FULL CONTROL. SDL is not under the mercy of some third party service, if anything happens to the SDL servers, they can fix it themselves and not have to wait. Yes, GitHub SHOULD have 99.99% uptime; and so should Google Mail, but they’ve been down a few times. Size of a company does not matter. Why don’t they move to their own Git server then? Because right now their setup works for them, so why fix something that’s not broke or incredibly inefficient?
At least one dev has confirmed that they have a Git server; so it’s not an issue of them not being able to use it.
I would love to see an official git mirror, Github or not, if only to have something vaguely trustable when setting up a git submodule link. I don’t particularly care if it is on Github, icculus.org, or other. Yes, there are other git mirrors, but I am, and probably always will be, suspicious of them. I’m pretty sure that I am not the only one who feels this way either.
For Sam and/or Ryan, if a bit of time and or money is needed for an official git mirror (Github or not), I’d be happy to toss a bit of either in. I should have a bit more free time than usual, for the next month or so.
FWIW, we run unofficial mirror for years from 2012 and we’ve got just seven pull-requests so far ( https://github.com/spurious/SDL-mirror/pulls?q=is%3Apr+is%3Aclosed ) . It’s up to readers whether or not consider the count is too many for the project, but I assume it is not too much.
There’s a few patch request using Git format is filed on the official bugzilla (e.g. https://bugzilla.libsdl.org/show_bug.cgi?id=4219 ) but I don’t think these are from the mirror. Creating local mirror can be done just few steps and it’s really easy thing…!
The major use-case of the unofficial mirror repository is “embed” SDL inside a git-managed project; for example my xbox port of Irrlicht ( https://github.com/okuoku/irrlicht-uwp ) imports slightly patched SDL2 inside the project because the required patch clearly not approved by the upstream in regard of performance vs. maintenability (drop use of GLOB on CMakeLists, allow static linking of GLES2 for performance, adding trace probes, static linking against ANGLE for optimization … some of patches are not pushed (yet))
I guess introducing “official” ones won’t change the situation much. In other words, most folks actually read repository description and won’t make pile of issues/pull-requests on the repository.
