Hey Sandro, There has been no feedback on the docstrings in the last 10 months. I'm sure dumping everything in a large MR was a bad idea to try to get this going...
So how can we make this more review-friendly? I'm planning to submit the changes step by step again over the next few weeks/months. Each MR will be limited to just a few functions from a single submodule, and accompanied by improvements to the test suite (concerning the same functions). Step 1: https://salsa.debian.org/reportbug-team/reportbug/merge_requests/11 Is this better? What would be the ideal MR strategy from your perspective? What do you think? On 21/02/2018 23.17, Nis Martensen wrote: > On 20-02-2018 06:02, Sandro Tosi wrote: >> On Sun, Feb 18, 2018 at 5:03 AM, Nis Martensen <[email protected]> wrote: >>> Extending the test suite is actually the goal here. It's just hard to >>> add tests for functions of which you don't know what they're supposed to >>> do exactly. So reading the code and taking notes is the first step. >> >> oh great to hear we're one the same page on that! :) > > I doubt it's going to be easy, though - many bugs are like > "proxy-related command line options don't work well" or "does not > interact nicely with my mua" or "crashes when user's homedir does not > exist". Not sure how those can be covered with unit tests. But let's go > step by step to figure out what's possible. > > >> i was more thinking of tools external to debian, like scripts from >> operators using those functions > > Hm. Are you aware of people having done that? Would the switch from py2 > to py3 not already have broken such tools? > > >>> Are you planning to move reportbug to salsa in the future? It might >>> make this kind of review easier. >> >> i just did and migrated reportbug to >> https://salsa.debian.org/reportbug-team/reportbug - wanna try the >> merge request thing ah! :) > > Here you go: > https://salsa.debian.org/reportbug-team/reportbug/merge_requests/1 >
