Re: [Monotone-devel] bugfest analysis

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Here is a little analysis of the recent bugfest efforts.

Thanks for all your work in organizing this.

> Point proposals from me are noted for "In test" issues. If no one else
> objects, please close the issues I marked accordingly yourself:
>
> 1) Assigned, but not (yet) closed issues:
>
> * #7221: [NEED TEST] "monotone cert" should not require its target
>   be on a branch
>   -> net.venge.monotone.bugfest-2010.7221-stephen_leake
>   -> @Stephe: Please look at my comment there. If you work that out,
>   an additional 2 point reward is for you :)

Fixed.

> * #13597: monotone update -b newbranch exhibits
>   incorrect behaviour
>   -> @Stephe: whats your plan here?

The latest comment in the bug explains my confusion; it can be closed.
It is currently marked "In Test".

> 2) Assigned, "In test" issues:
>
>...

I closed all of mine

> * #9269: [NEED TEST] monotone log doesn't understand windows directory
>   separator
>   -> net.venge.monotone.bugfest-2010.9269-stephen_leake
>   -> test looks ok for me (can't execute it here locally, though,
>   since I have no windows machine) - can be closed if the test
>   works
>   -> points: 2 to Stephe

I ran the test on both Debian and MinGW; it works.

Closed.

> * #12455: MT 0.16 can't access, if DB stored on NFS
>   -> I tend to agree that this is set on won't fix, while it might
>   still be a smaller issue in monotone (we should probably not
>   segfault, but provide a good error message, can anyone with an NFS
>   setup confirm that?)
>   -> points: 1 to Stephe

I think it's up to sqlite to provide a better error message. We could
file a bug upstream.

Closed.

>   -> points: 5 to Derek (if you add a test :)

Thank you for insisting on tests. The complete test suite is a major
feature of monotone; it makes the program much more trustworthy. I have
confidence that changes (made by me or others) will not break existing
behavior (or if they do, we will know about it).

One way to ensure tests get written is to adopt a development process
that always writes the test first, and always runs mtn in the context of
a test, not directly from the command line. I have a separate Makefile
for this, containing targets like:

mtn :
        make -C /home/Projects/monotone/bug-hunt-build mtn

# /home/Projects/monotone/bug-hunt-build/tester_dir/tests/undrop/tester.log
# /home/Projects/monotone/bug-hunt/tests/undrop/__driver__.lua
test :
        cd /home/Projects/monotone/bug-hunt-build; ./run_lua_tests -d undrop

That makes it very easy to rebuild mtn and run just the one test I'm
currently working on.

> * #13604: need 'undelete' ('undrop'?)
>   -> net.venge.monotone.bugfest-2010.13604-stephen_leake
>   -> patch looks largely cool, some minor objections:
>     "revert = not undrop;" - is the "not" operator portable?

Sorry about that; I was writing Ada code in a C++ context :(. Amazing
that it compiled!

Interestingly, Emacs highlites "not" as a keyword in C++. But I don't
see it in my copy of the C++ standard; maybe it's very new?

replaced by !.

>   -> possible issue left: undrop does not work correctly when
>      called on a dropped directory without --recursive. It still
>      re-creates all childs of the directory, while one would assume
>      that only the directory itself is recreated (and all the other
>      files keep dropped)

I think this needs discussing; I'll start a separate thread.

I've added tests to illustrate some of the issues.

> Lets breakdown the current points (not counting the not "in test"
> issues) so far:
>
> 1) Stephe   13 points (#7221 and #13597 still open)
> 2) Richard  11 points
> 3) Derek    5 points (#20447 still open, might add +5)
> 4) Tim            3 points (#17878 still open, might add +5)
>
> I'll give everybody some more time to cleanup / finish the mentioned
> things and recalculate the final scores again then.

I feel a little guilty about this. I deliberately adopted a strategy of
only working on trivial bugs. That was partly because I was tired and
not in the mood for hard work, but also partly because I felt it was in
the spirit of the bug hunt.

But others took on significant issues, and that should be rewarded.

Perhaps next time there should be two top prizes; "most bugs closed" and
"hardest bug closed", or perhaps "most effort expended" (measured by
changed lines of code, or something).

On the other hand, after a few bug hunts of only closing trivial bugs,
there won't be any left to close :).

--
-- Stephe