A workflow for bug fixing
As a developer in SUSE Desktop Department, most of my work are bug fixing. Desktop bugs are diversified in nature: you constantly need to handle bugs from an unknown package or some esoteric features. To comb with this reality, I’ve been pondering on the proper methodology.
About the diversities, here is a rhetoric saying with the 80-20 principle: 80% of the time we work with only 20% of the knowledge we need.
DISCLAIM: this post has undergone some format conversions and the current formatting quality is not very good.
You want to learn! And not timid before the unknown.
SRN: Search, Read, Note and repeat.
One of my main complaints about my last job in a local company is that they have regulated web access excessively in the office: in order to search for information I have to use common terminals that are constantly in short. IMO, this restriction contributes as half to the failure of the new project as all other factors combined. From that time on, I decide that I should refuse to work on any new project without decent web access.
Document reading is a trait that I believe many interviewers have overlooked (at least no one ever asks me about this part). In today’s fast-paced world, technology evolves quickly. Reading is the best way to keep in sync with the new developments.
Noting is more about recording what you’ve found. You need to mark what info you think are more important, more relevant, what questions or unclear points you still have. For this purpose, pen&paper is always my favorite.
A logical workflow.
The first two steps help you become comfortable with a new package or field. After you’ve been briefed with the context and you need to handle the problem itself. The reality is we still know only very little so the previous steps tend to appear again and again.
In short: problem -> questions -> solutions -> actions
Divide and rephrase the Problem.
Bug reports from customers or QA are never the appropriate way you should think about the bugs. Reproduce the bugs, be creative, try out different cases. Play with the problem till you can divide/rephrase the problem in a way you’re confident it can be addressed technically.
What is this? Why something work in A situation but not B? How the other program handle this situation? What if I do this?
Whatever the question you ask or encounter. Do the SRN.
Make the bold assumptions and leave questions unanswered.
A careful mind will always have more questions than what it can manage to answer in the limited period. Keep in mind the goal is fixing bugs, and questions can be dealt with by: making bold assumptions if all known facts fit, unanswered if not considered relevant, short answer if that’s sufficient.
I’ve always found assumption is a very effective way of moving things forward. A striking fact is human minds work similarly: many times what you think intuitively is not too far away from what others’ve done. As long as the exact detail is not needed, by making assumptions, we save us time and progress fast. (And there is little to lose, correct it if we assumed wrong.)
Iteration till a solution comes to your mind.
There are no recipes for locating the solution. It comes to you at proper time ;P after enough work along the right direction.
A workflow example
The rest of the article is a workflow document I’ve created while fixing a Desktop bug. It’s a reproduction as in work I actually only sketch on paper. I also would not include any references on the details because the outline is more important for ideas I’d like to share.
Related the component is in
As in my comment #3, the main issue is the misuse of GNOME Tweak tools.
Two real bugs remain: 1. Window buttons are not shown or displayed correctly across workspace. 2. Nautilus has issue dealing with window grouping.
FACTS & Questions
DONE How windows add&remove event gets detected?
this._workspaceSignals a hash map holds
window-removed listeners IDs.
The listeners are working as expected.
*FACT* The grouping works correctly in one single workspace.
DONE Q: How? And can we duplicate the logic to multiple workspaces?
_populateWindowList has check on the grouping setting. If the grouping is turned on,
AppButton is used, o/w
WindowButton is employed.
DONE Q Why only windows in current WS is displayed? (no grouping for simplicity.)
WindowList holds all window/app buttons. Each button is responsible for checking whether it should be displayed with regards to current workspace.
App and Window Button have different visibility criteria. More on this later.
AppButton is new to me.
Two implications only happens to me later: bugs that were fixed for
WindowButton should be ported to
WindowButton are similar in nature but do NOT share a same class hierarchy, which I believe is an issue.
####### TODO Should
WindowButton has a same parent?
To prevent duplicated code and emphasize the common role both play.
DONE Q: Why switching back&forth workspaces fixes button issues?
_populateWindowListrecreate all active window/app buttons, but this routine only run at
notify::allocation, which is NOT triggered with workspace change.
AppButtonis similar to
WindowButton, visibility check callback is hooked to
This finding leads necessarily to the first solution.
Solution: missing or legacy buttons.
AppButton visibility update callback into
windows-change signal from
- No button in new workspace if we open a new window for an already running application.
- Remaining legacy button in a workspace after all windows of one application is closed. NOTE, the application is still running, i.e. it has opened window in some other workspace.
Solution: Title problem
- Currently button title only gets updated with “windows-change”
[ ] “windows-change” is signaled even only by switching workspace
This explains why switching fixes some issues. But why this event gets triggered?
There is a bug in original code. It doesn’t consider the case when an application has two single window in separate workspace as it does nothing if
this._windowTitle exists. Forcing update to fix this.
- Incorrectly displayed title, see original bug report for detail.
DONE Q: an app gets its window list on current workspace? Specifically for
_getWindowList uses API
Shell_app_get_windows, which returns all windows belonging to a specific application.
win.located_on_workspace(ws) is used to check whether
win is in
Solution: Desktop is shown as a window in the panel with grouping on.
_getWindowListshould only check window types. Only return window of type
DONE Q: Why an
Nautilus button is still displayed even without
_updateVisibility uses API
shell-app.c), which according to this patch, will return
true for Desktop window (a workspace less window as we see).
(this._getWindowList() > 0) to test for visibility.
This is safe as
shell_app_is_on_workspace uses the same logic. The only difference is application in STARTING status and workspaceless window, both should be ignored anyway.
grouping is enabled, context menu is shaky and unusable, also a lot of stability issue.
- [X] “button-press-event” issue
this._appContextMenuif there is a single application window.
A patch has been submitted.
Both issues for demonstration 1 and nautilus have been fixed for SLE Classic.
In short the original code contains multiple grouping bugs.
Details: In total 4 separate bugs are identified and addressed. 1. Failure to update buttons visibility when windows are added/removed for an application. 2. Window title is not updated correctly. 3. When deciding what windows should be displayed as buttons, failed to exclude abnormal windows like Nautilus Desktop. 4. (Found in Development) Forget to manage appContextMenu, which, with grouping on, leads to instability and focus grabbing issue for button context menu
Further, I’ve overlooked AppButton in previous fix. So some patches for WindowButton is also ported to AppButton.
∎ Example End