Open Stack

On Mon, Feb 28, 2011 at 8:15 PM, Ewan Mellor <Ewan.Mellor at eu.citrix.com> wrote:
> If the “known_bugs” list isn’t being well received, how about this:
>
> # TODO(ewanm): Enable once bug #21212 is fixed
>
> if False:
>             assert(something)
>
> And then put a comment on bug #21212 saying “please also enable the
> following unit tests when you fix this bug”.

Hmm, I think the above has just as much chance (or more!) of producing
stale unit tests.

My thinking on this issue remains the following, repeated from the bug in OP:

This is the way I deal with it:

When you run into the bug:
* If it is a bug ONLY in code that you have just added in your branch,
then just fix the bug
* If it is a bug that is reproducible in trunk (i.e. not *just* the
topic branch you're working in):
  (1) File the bug in Launchpad
  (2) Do not fix the bug in your topic branch
  (3) If you want to assign yourself to the bug you just filed, then:
    a. Branch a bugfix branch from your local *trunk* branch (NOT your
topic branch)
    b. Add a test case to your bugfix branch that will trigger the bug
    c. Patch code to fix the bug and pass the test case
    d. Push to LP with --fixes=lp:XXXX where XXX is the bug number
    e. Propose for merging your bugfix branch into trunk

At this point, return to working on your original topic branch and
continue coding. If you *must* have the fix for the bug you just
reported, then do:

bzr shelve --all
bzr merge ../bugXXX && bzr commit -m "Merge fix for XXX"
bzr unshelve 1

If you don't absolutely have to have the fix for bug XXX in your topic
branch, don't merge it, since there's really no need to...

-jay