Ben, For backported fixes that are simple, do you see any reason not to make them directly in the 1.1-maintenance branch, to start with?
And for new bugfixes, I hope you don't object to them being made in both trunk and 1.1-maintenance, but not in this new branch, since each branch they need to be made in adds work. - Bruce On Sun, Aug 16, 2009 at 12:41 PM, Ben Smith <[email protected]>wrote: > > Howdy, > > I've made a branch to backport issue fixes from the trunk with the > intention to eventually merge it with the 1.1-maintenance branch. I > realize that there isn't an absolute consensus on whether this is > where things should go, but it's an instructive way for me to get into > the project code, and I feel that it's likely to be useful, and the > only project cost is the space used for the branch. It's my goal here > to have all issues that are fixed in 1.2dev to be fixed in > 1.1-maintenance, so that the issue tracking will be synchronized to > both branches - in other words I want to make it so all issues already > marked as fixed in the trunk are also fixed in 1.1-maintenance, where > applicable. > > So far the patches have been very small. Typos, single function > changes, stuff like that. > > So far, on this branch I have addressed these issues: > > 2338: Issue 353: xlib key symbol mismatch when shift key held. > 2337: Issue 361: mouse dx/dy incorrect when window freshly mapped > 2326: Issue 355: hex and octal constants parsed by wraptypes. > 2325: Issue 358: spelling fix. > 2237: Fix double flip problem when manually running event loop on > win32 (e.g. WINDOW_INTIAL_FULLSCREEN test). Possibly fixes issue 335. > 2227: Issue 334: check no modifiers present for ESC close window > shortcut > 2170: Issue 328: always clean build dir before creating mpkg dist. > 2158: Issue 275: return True from EventDispatcher.dispatch_event if > the event was handled. > > The r2169 commit log message references an issue description marked as > Invalid, but code changes were made to it. I haven't touched it yet. > 2169: Issue 319: unschedule leaving dummy funcs in schedule list > behind > > The list I'm working off of I posted here: > http://groups.google.com/group/pyglet-users/msg/665323ab1d15ea2d?hl=en > > If anyone else wants to work on these right now, shoot me an email and > we can avoid duplication of effort. > > -b > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
