The first bug I filed was marked as duplicate; the second was worksforme (although Chris Petersen could reproduce it before he couldn't anymore); and the third was invalid (it was the spec, not the code, that was errant). The fourth is the first that was fixed.
2011-09-16
2011-09-09
"Next/Previous Tab" Keyboard Shortcuts on Windows
On my Windows laptop, I use the following four programs with tabbed interfaces on a regular basis:
Unlike on my Mac, all those programs implement the same keyboard shortcut for switching to the previous/next tab, and it's a simple one with just a two-key chord: Control + PageUp / PageDown.
Ha!
- Firefox
- Thunderbird
- Instantbird
- Komodo IDE
Unlike on my Mac, all those programs implement the same keyboard shortcut for switching to the previous/next tab, and it's a simple one with just a two-key chord: Control + PageUp / PageDown.
Ha!
2011-09-08
"Next/Previous Tab" Keyboard Shortcuts on Mac
On my Mac, I use the following five programs with tabbed interfaces on a regular basis:
And those programs implement the following five different keyboard shortcuts for switching to the previous/next tab:
- Firefox
- Thunderbird
- Adium
- Terminal
- Komodo IDE
And those programs implement the following five different keyboard shortcuts for switching to the previous/next tab:
- Control + PageUp / PageDown (Firefox, Thunderbird)
- Command + LeftArrow / RightArrow (Adium)
- Command + PageUp / PageDown (Komodo IDE)
- Command + Shift + [ / ] (Terminal)
- Command + Shift + LeftArrow / RightArrow (Terminal)
2011-09-07
gitflow vs. the SDK
gitflow is a model for developing and shipping software using Git. Add-on SDK uses Git, and it too has a model, which is similar to gitflow in some ways and different in others. Here's a comparison of the two and some thoughts on why they vary.
First, some similarities: both models use multiple branches, including an ongoing branch for general development and another ongoing branch that is always ready for release (their names vary, but that's a trivial difference). Both also permit development on temporary feature (topic) branches and utilize a branch for stabilization of the codebase leading up to a release. And both accommodate the occasional hotfix release in similar ways.
(Aside: gitflow appears to encourage feature branches, but I tend to agree with Martin Fowler through Paul Julius that continuously integrating with a central development branch is preferable.)
Second, some differences: the SDK uses a single ongoing stabilization branch, while gitflow uses multiple short-lived stabilization branches, one per release. And in the SDK, stabilization fixes land on the development branch and then get cherry-picked to the stabilization branch; whereas in gitflow, stabilization fixes land on the stabilization branch and then get merged to the development branch.
(Also, the SDK releases on a regular time/quality-driven "train" schedule similar to Firefox's, while gitflow may anticipate an irregular feature/quality-driven release schedule, although it can be applied to projects with train schedules, like BrowserID.)
A benefit of gitflow's approach to stabilization is that its change graph includes only distinct changes, whereas cherry-picking adds duplicate, semi-associated changes to the SDK's graph. However, a downside of gitflow's approach is that developers must attend to where they land changes, whereas SDK developers always land changes on its development branch, and its release manager takes on the chore of getting those changes onto the stabilization branch.
(It isn't clear what happens in gitflow if a change lands on the development branch while a release is being stabilized and afterward is identified as being wanted for the release. Perhaps it gets cherry-picked?)
Overall, these models seem fairly similar, and it wouldn't be too hard to make the SDK's be essentially gitflow. We would just need to stipulate that developers land stabilization fixes on the stabilization branch, and the release manager's job would then be to merge that branch back to the development branch periodically instead of cherry-picking in the other direction.
However, it isn't clear to me that such a change would be preferable. What do you think?
First, some similarities: both models use multiple branches, including an ongoing branch for general development and another ongoing branch that is always ready for release (their names vary, but that's a trivial difference). Both also permit development on temporary feature (topic) branches and utilize a branch for stabilization of the codebase leading up to a release. And both accommodate the occasional hotfix release in similar ways.
(Aside: gitflow appears to encourage feature branches, but I tend to agree with Martin Fowler through Paul Julius that continuously integrating with a central development branch is preferable.)
Second, some differences: the SDK uses a single ongoing stabilization branch, while gitflow uses multiple short-lived stabilization branches, one per release. And in the SDK, stabilization fixes land on the development branch and then get cherry-picked to the stabilization branch; whereas in gitflow, stabilization fixes land on the stabilization branch and then get merged to the development branch.
(Also, the SDK releases on a regular time/quality-driven "train" schedule similar to Firefox's, while gitflow may anticipate an irregular feature/quality-driven release schedule, although it can be applied to projects with train schedules, like BrowserID.)
A benefit of gitflow's approach to stabilization is that its change graph includes only distinct changes, whereas cherry-picking adds duplicate, semi-associated changes to the SDK's graph. However, a downside of gitflow's approach is that developers must attend to where they land changes, whereas SDK developers always land changes on its development branch, and its release manager takes on the chore of getting those changes onto the stabilization branch.
(It isn't clear what happens in gitflow if a change lands on the development branch while a release is being stabilized and afterward is identified as being wanted for the release. Perhaps it gets cherry-picked?)
Overall, these models seem fairly similar, and it wouldn't be too hard to make the SDK's be essentially gitflow. We would just need to stipulate that developers land stabilization fixes on the stabilization branch, and the release manager's job would then be to merge that branch back to the development branch periodically instead of cherry-picking in the other direction.
However, it isn't clear to me that such a change would be preferable. What do you think?
Subscribe to:
Posts (Atom)