Posts: 5,174
Joined: Jan 2010
Reputation:
97
Kib
Team-Kodi Member
Posts: 5,174
I believe this has already been fixed.
Posts: 256
Joined: Dec 2009
Reputation:
1
That's great. But it's also what I was told for XBMC asking twice for keeping the screen resolution and it was not. Not saying this isn't fixed already. But maybe stronger linking between existing tickets to be followed and this forum would be great for both devs and users?
Posts: 31,445
Joined: Jan 2011
The screen res thing did get fixed, it just got rebroken later on :)
But yes, when in doubt, it never hurts to file a bug report. (and agreed that trac's search really sucks)
Posts: 5,174
Joined: Jan 2010
Reputation:
97
Kib
Team-Kodi Member
Posts: 5,174
I was looking for the fix itself, but haven't been able to find it.
I remember seeing it either being discussed by teammembers or seeing a commit being pushed to master that fixed it. Obviously I could be wrong, so you better take my statement with a grain of salt.
Could you do me a favor and test it with a nightly to see if it has been fixed ?
Posts: 256
Joined: Dec 2009
Reputation:
1
Tested with nightly build of Aug 9th on OS X working fine so consider this fixed.
Not so much for the screen resolution bug. Still happening. I'd be most happy if I was never asked that question. If I switch to fullscreen then "yes" I want to keep that resolution. If I switch back to window mode "yes" I want to keep the resolution. I'd assume 99% of all clicks in that dialogue go to YES. Is it really worth bothering the user with that questions that often?
Posts: 256
Joined: Dec 2009
Reputation:
1
This still happens with the latest nightly and Ubuntu 12.04. No longer a problem on OS X. The interesting thing is, this works when firing up XBMC on ubuntu and going straight to the exit menu item. Then it works. But when using xbmc for a while (I mostly access that ubuntu system via upnp) then XBMC gets stuck once Exit is selected via the menu item.
Posts: 12,706
Joined: Nov 2003
Reputation:
129
spiff
Team-Kodi Member
Posts: 12,706
we are aware of the issue, but we have not found a fix. it's painful assumptions in python that is the root cause. a python thread can never migrate between system threads and at exit we try to kill em all from the app thread.
Posts: 256
Joined: Dec 2009
Reputation:
1
Hi Spiff, thanks for the response. Maybe it's just me, but I don't get the workflow of XBMC devs. It seems tickets are not used that much? Maybe most things are done via IRC? I have no insight. But since there is trac I'm not sure why bugs like this one are not in there. Or if they do exist why no links are posted on the forum.
For me personally, it would be ideal, to report a problem, maybe create a ticket on trac if demanded and then follow progress via subscribing that ticket. Currently all I have is this forum thread which may not get update should the bug be fixed.
Maybe there's another idea behind the current workflow?
Posts: 12,706
Joined: Nov 2003
Reputation:
129
spiff
Team-Kodi Member
Posts: 12,706
discussions do happen on irc. tickets are really just used as reminders for stuff nobody feels like putting on their todo, trac is pretty useless as a development tool, it's an end user thing.. you'll find devs are mostly active on github.
Posts: 256
Joined: Dec 2009
Reputation:
1
spiff, well what I don't understand is, how a project of the size of XBMC can get managed without a bugtracker (if trac is indeed only an end user thing) and github does not use issues.
Posts: 31,445
Joined: Jan 2011
(2013-09-08, 17:38)Syncopation Wrote: spiff, well what I don't understand is, how a project of the size of XBMC can get managed without a bugtracker (if trac is indeed only an end user thing) and github does not use issues.
I think he means that trac is just an end user thing for reporting. Trac is very helpful in getting those. Some of the Team XBMC devs will use Trac, even if it's mostly to just catch end-user reports.
As far as progress reporting on fixing issues, that's mainly up to whoever is working on the issue. We have a mix of personal notes, Team threads in our internal forum, various discussions, and more. Often it's a case where only one or few people are working on an issue, so as long as they are able to coordinate between each other, that's all that is needed.
However, it's not always the best way to do things. We are looking at how more internal things can also be external things, so everyone can see what's going on. Even then, whatever methods or system we come up with, it has to be something that XBMC developers are comfortable with using. Team XBMC is a big mix and mashup of different personalities and styles. People get used to doing things a certain way, so sometimes new ideas will take time. Just know that we are keeping an open mind for new ideas :)
Posts: 256
Joined: Dec 2009
Reputation:
1
Ned thanks for explaining things. I'm very aware that XBMC has a huge dev community and work flows develop and evolve over time. As you pointed out, I just think if there is some system that openly shows progress it's easier to track progress.
This issues is still valid on Ubuntu 12.04 and latest XBMC nightly (FYI).
Posts: 256
Joined: Dec 2009
Reputation:
1
And with 13.10 latest XBMC nightly still valid.
