The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I installed TortoiseHg, and clone SDL2 project from http://hg.libsdl.org/SDL. "HG Commit..." my patch to newest branch successfully.

Next, I push it to http://hg.libsdl.org/SDL, and fail. Fail reason: Privilege grant failed. I guess, I do not have the authority to update the source. Now, how to get the authority?

There is content I want to patch. https://github.com/freeors/SDL

Go through bugzilla, and submit a patch.  If anyone could just push updates to FOSS projects, they would all just be a mess.

https://bugzilla.libsdl.org/



Add a new bug, describe what your patch does, attach the patch, and other will review it.


On Sun, Aug 7, 2016 at 7:58 AM, ancientcc wrote:

I had created BUG:3406, https://bugzilla.libsdl.org/show_bug.cgi?id=3406

If there are serval files, it will be difficult to describe.

In github, you can generate diff and patch files, which is what you'll want to share.  I think the easiest way to to create a branch, then a pull request, but that is assuming you are working from SDL's repo, and also that you're using mercurial instead of git.

If you've just been committing to master on your github page, the github flow I described is going to be painful.  You might be able to find tools that create .diff or .patch files by comparing two directories, so you could do a checkout of SDL's mercurial and your git.  Doing a quick google search got me a few results, and http://stackoverflow.com/a/2463534/661764 looks promising.


Ultimately, I can guarantee no one is going to manually look through your repo and attempt to identify differences, it's up to you to be able to provide a patch or diff file.


Your bug report looks fine, and attaching either a diff or patch will make it much easier for people to see what changes you have made, and be able to apply those changes locally so they can test for bugs.  Also, have you ran the SDL tests?  Make sure you run everything in test and visualtest (looks like http://hg.libsdl.org/SDL/file/42768c568a50/test/testrendertarget.c has some contact with SDL_RenderReadPixels) to ensure your changes don't accidentally make other tests fail.


On Tue, Aug 9, 2016 at 9:57 AM, ancientcc wrote:

Thank you so much detailed explanation.

Using testrendertarget.c, I did not test the commited patch about SDL_RenderReadPixels. But I had released serval app calling SDL_RenderReadPixels, for example, https://itunes.apple.com/us/app/zhi-ma-shui-mian/id1068347573.

At present, what I most want is to patch BLE to the official SDL. But for this module, in addition to modify  existing file, but also add to at least 7 files. By means of commiting bug to https://bugzilla.libsdl.org, it is estimated that this requirement is difficult to describe.

Recently, I will write an app that auxiliary BLE hardware development. I want to consider how to patch after completion of this app.

Even so, make sure it passes that test.  Unit tests are designed by the original developer to test for known outcomes.  The point isn't about whether it works, it's about whether it does the expected thing.

If you can't easily give a diff or patch, I guarantee that your bug will be rejected.  I've already provided a link that describes creating a .diff file that would be appropriate to attach to the bug.  A diff file will capture changes among multiple files, so I'm not sure what your objection is.


On Wed, Aug 10, 2016 at 11:03 AM, ancientcc wrote: