bs_maintenance_backports branch

[Ben Smith]

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

[Bruce Smith]

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

[Ben Smith]

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 <ores...@gmail.com> 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

> <benjamin.coder.sm...@gmail.com>wrote:

[Bruce Smith]

On Sun, Aug 16, 2009 at 2:24 PM, Ben Smith <benjamin.c...@gmail.com> wrote:

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

My view is that it's better to commit directly to 1.1-maintenance -- this reduces potential confusion, reduces potential eventual merge conflicts, and requires less coordination. (And if you make a mistake, you or someone else can always revert it -- it's not a big deal.)

But, as only one of the interested parties, I am totally sympathetic with your waiting for an "ok" from the others. But I would point out that other committers are already committing directly to 1.1-maintenance (I think), and I also plan to do that if I have time to do any commits.

- Bruce

[Bruce Smith]

On Sun, Aug 16, 2009 at 2:24 PM, Ben Smith <benjamin.c...@gmail.com> wrote:

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.

Another point about that -- I think that though the consensus is not fully firm, one of two courses is almost certain as of now -- either release next from 1.1-maintenance, or abandon it (releasing next from trunk == 1.2dev -- much less likely). But either way, there is no *harm* in backporting a bugfix from trunk to 1.1-maintenance -- there's just a small danger that it's wasted work.

- Bruce

[Richard Jones]

On 17/08/2009, at 7:32 AM, Bruce Smith wrote:
> My view is that it's better to commit directly to 1.1-maintenance --
> this reduces potential confusion, reduces potential eventual merge
> conflicts, and requires less coordination. (And if you make a
> mistake, you or someone else can always revert it -- it's not a big
> deal.)

I agree with this.

Richard

[Richard Jones]

I think there's a lot of value in releasing a 1.1 version in time for pyweek that fixes some commonly-encountered bugs.

     Richard

[Ben Smith]

Well cool. I'm signing off for the night, but I managed to get a
substantial portion of the closed issues from 1.2dev(trunk) applied to
bs_maintenance_backports. I have *not* run the tests on this yet, so
things on this branch are unverified. There are also a few issues
that were lodged against trunk code that didn't apply to the 1.1-
maintenance branch.

here are my notes on what is not in this bs_maintenance_branch that
exist in the trunk

2420: Issue 377, scroll wheel broken on win32.
* uses 1.2dev features

2169: Issue 319: unschedule leaving dummy funcs in schedule list
behind

* This commit seems unrelated to issue 319 which was marked as
Invalid.

2422: Issue 380: OS X input typo
* uses 1.2dev features

2423: Issue 379: setup.py package list out of date
* uses 1.2dev features

2424: Issue 368: fix executable bits of various files, remove shebangs
from non-exec files, fix line-endings on NOTICE.
* I'm developing on windows, I'm not sure how I'd make permission
changes

2430: Issue 390:
* trunk/pyglet/info.py wintab isn't part of pyglet 1.1?
* trunk/pyglet/media/drivers/silent.py has been refactored in 1.2 and
these changes apply to the 1.2 version

2434: Issue 393:
* trunk/pyglet/app/base.py isn't in pyglet 1.1?
* branches/1.1-maintenance/pyglet/app/carbon.py isn't importing
Queue.
* experimental/input/linux.py changes need testing on linux
* experimental/input/wintab seems to rely on trunk refactoring
* file x11_xinput_tablet.py doesn't exist in 1.1

2454: Issue 409: putting back pyglet.media.have_avbin
* looks like it doesn't apply to 1.1

2452: Issue 381:
* backported to bs_maintenance_backports as r2484 - original r2452
* Should we review this one? Sounds like there may still be
problems.

2344: Issue 294: Clarify Texture.create(rectangle) parameter, add
force_rectangle parameter.
* This adds a parameter to several functions. I made it default to
False in one additional place to keep the API compatible. Depending
on policy, this may have to be in 1.2dev because it does change the
API, though the API is still backwards compatible.

2465: Issue 405: Added commented code to retrieve unicode character on
_get_gsymbol_and_modifiers method
* didn't merge in commented code

2460: Issue 418: Added float division in 2in32 mousewheel event
* This change is under active discussion

I think that covers it all.

-b

On Aug 16, 2:47 pm, Richard Jones <r1chardj0...@gmail.com> wrote:
> On 17/08/2009, at 7:35 AM, Bruce Smith wrote:
>

> > On Sun, Aug 16, 2009 at 2:24 PM, Ben Smith <benjamin.coder.sm...@gmail.com

[Bruce Smith]

Ben,

Here is another item for your list (copying part of my reply in another thread where someone hit this bug just now):

http://code.google.com/p/pyglet/issues/detail?id=407 (pyglet issue 407), whose comments say it's fixed in trunk (r2327) but not in the 1.1-maintenance branch (and not in any release). I think that's the pyglet bug most often encountered in the last pyweek.

- Bruce

[Ben Smith]

Thanks, I just ran across that one. Looks like an easy fix, but I
should wait until I'm off work =T

Any others that'd be good to have?

-b

On Aug 17, 11:11 am, Bruce Smith <ores...@gmail.com> wrote:
> Ben,
>
> Here is another item for your list (copying part of my reply in another
> thread where someone hit this bug just now):
>

> http://code.google.com/p/pyglet/issues/detail?id=407(pyglet issue 407),