Joysticks pref crashes when usb gevice plugged in

[Disreali]

Experienced on hrev44378-2h and hrev44418-2h.

As long as a USB game device is plugged in, Joysticks crashes with the attached backtrace.

Steps to reproduce:

Step 1: Build Joysticks pref

Step 2: Launch Joysticks with usb gamepad/joystick plugged in.

• pref crashes

Step 3: Unplug gamepad/joysick.

Step 4: Re-launch Joysticks

• pref works fine

I have no gameport with which to test.

There is no Joysticks component under Preferences for TRAC.

Also, beside it not working for usb, why is the Joysticks pref not part of the base image?

[Disreali]

Forgot to mention that I am testing with a Logitech Cordless RumblePad2.

[luroh]

Moving out of R1 milestone (FutureHaiku/Features).

[modeenf]

Tested with a Logitech Precision on hrev54064. No crash. Didn't work as expected (told me that I didn't had a device to proble but could test to probe it any way.) but did show the device as usb/0 when I hade my Gamepad attatched.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

[pulkomandy]

Well, since Joysticks isn't shipped in the beta2 image, I wouldn't put this one there.

[modeenf]

can it be activated in nightly?

[pulkomandy]

Joystick settings will be integrated in Input preferences instead, so I would not spend too much time working on the existing panel.

[nielx]

Remove target milestone.

[pulkomandy]

Hi nielx; normally we use the unscheduled milestone for this (tickets that are not planned for R1, but don't require compatibility breaks and thus need to be in R2), why remove it?

[nielx]

The logic is that when a ticket is open, the Milestone field should reflect the release for which it is planned. Our project does not particularly do a lot of planning, so in general we have the milestone:R1 for issues that should be looked at for R1 and the milestone:Unscheduled milestone as placeholder for 'Someday'.

So meanings of milestones for open tickets:

• milestone:R1 is a catch all for issues that we may want to look at before releasing R1, though it could use some curation due to the fact that originally this was the 'Someday' milestone
• milestone:Unscheduled is the default milestone, and means 'Someday'. It was created to dissuade users to set milestones themselves
• milestone:R2 are tickets (mostly enhancements) that are definitely not R1 because they would imply binary incompatible changes.
• milestone:R1/beta2 and milestone:R1/beta3 are scheduled milestones (i.e. they have a release date) and are used to discuss concrete requirements/blockers for each release
• Special case are non-software tickets (website, sys admin), which would either be in milestone:Unscheduled or without a milestone set.

When a ticket is closed with resolution fixed, the Milestone should reflect the next release this fix will be a part of. For practical reasons, it helps with generating a list of things that have changed for the interested parties. Aesthetically, it just looks cool that milestone:R1/beta2 is 99% done now. Tickets that are closed with resolution duplicate, invalid, no change required, junk or 'not reproducible' will not be delivered as part of a release, and as such the milestone should be unset.

In this concrete case, if I apply the logic above, based on the status of the ticket set in comment:3 this issue is fixed in milestone:R1/beta2. As per comment:5 the panel is not in beta 2 image, so it won't be delivered as part of any milestone, which is the logic for unsetting the milestone field.

(As an aside: arguably the resolution was never fixed but rather no change required as the panel is no longer in use. This leads to the same outcome milestone though. As an alternative I could also reason that it is part of the R1/beta2 code base, so in that sense it is delivered as part of milestone:R1/beta2).

My apologies, these thoughts have formed in my mind over the past few weeks and have yet to be put up for review on the mailing list.

[pulkomandy]

Ok, there is just some disagreement between us on the use of the "Unscheduled" milestone then. I agree with all the other parts (except the fact that we don't do a lot of planning, we are indeed triaging the issues between the different milestones already).

I would prefer that tickets are created with no milestone set, and that they are then triaged, usually, to R1 or R2 as you mentionned. For each beta, we can cherry-pick what we plan to include and move from R1 to the relevant beta milestone.

The Unscheduled milestone would then be for things that are not part of the R1 roadmap, yet can be done in R1 because they don't require ABI breakage (unlike tickets that are put in R2).

And, yes, as the tickets are closed we should move them to the milestone matching the release they're shipped in, although I had suggested this a few years ago and there wasn't much agreement. Anyway, it's largely done now. Note that if we had done it from the start, sure, beta2 looks like it's 99%, but the R1 milestone would be at 0, because all closed tickets would be in past releases. I don't know which is more useful, the short-term view of the next release, or the long-term goal of progress towards R1.

Probably doesn't matter too much either way :) let's move on to the still open tickets instead :D

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone