Suggestions on good first bugs

Daniel Näslund dannas at dannas.name
Thu Mar 5 11:53:18 PST 2015


Hi,

I'm looking for good first bugs. Something that I can finish in a few
evenings that helps me sort of the structure of the code base.

The TODO wiki page links to
https://github.com/mozilla/rr/labels/goodfirstbug.

#1153 Remove constraint on srcdir/objdir...
    I was bitten by this when I first tried to build. I'll make an
    attempt (though I despise every build system just as much as any
    other developer).

#1054 Implement remaining syscalls
    Rocallahan says [3]
    "I think we shouldn't clutter up rr with support for syscalls that no-one
    ever uses in practice (e.g. because they're obsolete). So I think
    anytime someone submits a patch supporting a syscall, we require some
    evidence that it's actually needed (e.g., someone says they hit it
    recording some program)."

    Any syscalls that we know are needed?

Other suggestions? ===

rocallahan said in [2]:

    "Even just installing an unrelated package could cause problems.
    Probably we should always just copy /etc/ld.so.cache into the trace so
    that you can do Unrelated package changes without invalidating traces."

    Is that something that is feasible? Needed?

cgjones said in [4]

    "To narrow things down, you can check the "SigCgt" (et al.) entries in
    /proc//status to see what linux thinks the signal setup is. It would be
    super great to add another function for rr's "check mode" that ensures
    rr's view of signal setup is the same as linux's. We do this for the
    memory map already."

    Is that something that can be done as a first-time project?

Any other suggestions on first good bugs?

Thanks for the all the friendly, helpful and quick replies I've received
so far.

Daniel (dannas) Näslund

[2] https://github.com/mozilla/rr/issues/1398#issuecomment-77246191
[3] https://github.com/mozilla/rr/issues/1053#issuecomment-40584202
[4] https://github.com/mozilla/rr/issues/1424#issuecomment-75667370


More information about the rr-dev mailing list