Finding a patch's kernel version with git
Posted Jun 20, 2010 21:35 UTC (Sun) by farnz
In reply to: Finding a patch's kernel version with git
Parent article: Finding a patch's kernel version with git
Consider the following arrangement (which isn't uncommon); development takes place on the main branch (trunk in SVN terminology). When a release is made, the release manager tags it with a tag like "release-4-0-0", and they also create a "maint-4-0" branch for bugfixes only. Development of new features continues apace on trunk, leading towards a 4.1 release (tag "release-4-1-0", branch "maint-4-1").
During a deployment of 4.0.0, a bug report comes in; as the sustaining engineer responsible for 4.0, I have a copy of the maint-4-0 branch checked out, as well as a copy of trunk. It's late on a Friday, but as the bug reporter is important, I diagnose the bug, discovering that it's an obscure interaction between something very specific in their configuration and our software. Because it's an obscure interaction, it's unlikely to be seen by anyone else, and automated testing won't catch it. However, it's a simple bug to fix, so I code the fix, check it in, and send the reporter a hotfix to test.
I duly note in the bug tracker that I've checked in a fix, SVN revision 155234. Process tells me that I need to forward port the fix to trunk as well as check it in to maintenance, but I'm now very tired, and don't trust myself to forward port it properly, so I leave it, fully intending to come back and do the rest of the job later.
Life intervenes, and I forget. The only formal record of the problem says it was fixed in revision 155234; my colleages note that trunk is now at 156974, and assume that the fix is in trunk. Because we got ahead of plan on feature development, 4.1.0 is ready before we've accumulated enough minor bugs to make a 4.0.1 release worthwhile; we can tell from the revision number that my fix is after 4.0 was released, but before 4.1 was ready. The resulting assumption upsets the original bug reporter, because they saw a 4.0 release that failed, a quick fix that I said was checked in, and a 4.1 release that fails again in the same way.
And before you claim this is unrealistic, that no-one uses SVN like this, please be aware that I've not worked anywhere in the last 10 years that uses centralised VCS (not just SVN, but commercial VCS as well), and doesn't use it like this. Most large projects have a need for branches - if nothing else, one for development, one for maintenance, so that users can pick up just bug fixes to the latest release without picking up half-baked new features too.
to post comments)