Well, the main reason I did it this way is because I didn't feel that there was firm consensus as to what should be done. I don't mind doing this work on the maintenance branch instead, I just didn't want to go committing to an 'official' branch without other people weighing in - yet I wanted to *do* something.
I agree with you, the more branches the same work is done in, the more complicated things get. My social concern is the only motivation for this branch. I'd like to merge it in as soon as possible, if it's not going to cause problems. Matter of fact, while others are working on still open issues in the 1.1-maint branch I can go over these closed in 1.2 issues without much problem. So, if people want these changes on the 1.1-maintenance branch, I'll put them in. I'd like to wait a day or two to hear from interested parties before I do any committing on an 'official' branch. -b On Aug 16, 1:43 pm, Bruce Smith <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
