Finding a patch's kernel version with git
Posted Jun 21, 2010 8:52 UTC (Mon) by farnz
In reply to: Finding a patch's kernel version with git
Parent article: Finding a patch's kernel version with git
Actually, this is based on real events - it does happen like this in the real world, because I've been there to experience it. My colleague noted the revision number in bugtracker, expecting it to be obvious and implicit that he was working on the maint branch, because he was the sustaining engineer for that version (as well as working on features for the new version). He forgot (human error, it happens) to forward port it, or to flag that he hadn't done so.
When the release manager looked to see if all bugs were fixed, they assumed (because this is true for most bugs in our bugtracker, and because we'd decided relatively early in the process to skip 4.0.1, so very little work had been done on maint - it was just bad luck that this was one of the first "in-the-field" bugs for that release) that the fixed-in revision was for trunk, and thus assumed that it was fixed in trunk but not maint.
Had we done a 4.0.1 release, this would have been caught, as the release manager would have noticed then that he had a bug fixed in maint but not on trunk, or in trunk but not maint (either way round, not acceptable). Had we not decided relatively early to skip 4.0.1, it would have been obvious that we had bugs from 4.0.0 which only had one fixed in revision, so that we couldn't have fixed them on both trunk and maint. However, most bugs from 4.0.0 were just fixed on trunk, because we knew we weren't going to do a 4.0.1.
Had the revision number not been so "obviously" ordered, we'd have not made the mistake either; CVS style revision numbers would have protected us, because it would have been clear that the fix was on a branch only, and DVCS-style commit hashes would have protected us, because we'd have to ask the tools to tell us which branches contained the fix. Indeed, had we not had "obviously" ordered revision numbers, the release manager would have used the tools we'd built on top of SVN to confirm that bug fixes were in trunk as well as maint - it was the combination of very few fixes actually made to maint, and the hassle of running the tool when it was "obvious" from revision numbers that the fix was in the release we were about to make that resulted in this bit of human error.
Of course, this takes us a long way from your claim that this is an advantage of CVCS - you had said that all I had to do was look at revision numbers; I've given you a counterexample from experience where the ordering of revision numbers resulted in human confusion, and you're saying that it couldn't have happened like that, because people don't make that sort of mistake.
to post comments)