inspiration from brew brew gist-logs

[timotheecour]

I know you mentioned Why not use GitHub API?. but perhaps this is a bit different; i find brew gist-logs quite convenient, and allows to put more information there which would probably not be good to have embedded inside a github issue (eg this could negatively impact search by causing too many terms to point to the output log)

so there could be an analog nimbug gist-logs, with a commandline/API to be determined. Just throwing out this idea, which needs some refinement.

eg output: https://gist.github.com/timotheecour/f7dc4baa86f256695307731e35177dde
each homebrew issue requires it, see https://github.com/Homebrew/homebrew-core/issues/new?template=bug.md

[juancarlospaco]

Not sure I understand, making the Links mandatory ?,
I dont think is good idea, the point of the tool is to work with all sizes of projects,
Ban a user for not adding a link I think is kinda silly, will make people report less bugs.

I want to make NimBug more language agnostic, while still useful for Nim,
lets say Python or JavaScript projects can use NimBug.

[timotheecour]

Not sure I understand, making the Links mandatory ?,

no, that wasn't my point; my point was the way brew gist-logs works, which automatically uploads a gist (eg gist.github.com/timotheecour/f7dc4baa86f256695307731e35177dde) when you run brew gist-logs, so all you need is to add a link to the gist in the bug report instead of copying the content in the bug report. It's still language agnostic.

but feel free to close, I won't mind :)

[juancarlospaco]

Sounds like a good feature, ...but thats a thing that works with a fixed program,
I want NimBug to work even for simple scripts that dont even have a Logger,
so I dont know how that would play with that.

I would leave the Bug open, I would merge PR for this if someone has idea how to implement it.

[juancarlospaco]

I think that slightly more important is the fact that very few people are using it,
this will work if people use it, otherwise we keep receiving "wont work" bug reports,
if we add more mandatory stuff even less people will use it, how can get more people to use it?.
🤔

[timotheecour]

people will eventually use a tool if it adds real value (even if it only benefits whoever's triaging/fixing the bug). Once the tool is good enough, we can add it to nim's issue template as a required step; many github projects have required steps in their issue templates and that has never stopped ppl from sending issues (eg see https://github.com/tmux/tmux/issues/new or https://github.com/Homebrew/brew/issues/new?template=bug.md or many more). Avoiding issue template is occasionally fine if user has good reason.

The end goal is to reduce the work on whoever's going to fix/triage the bug (for a tiny bit more work on the bug author, and deferring as much work as possible to automation)

In my ideal world this would work:

• user submits a bug, following (possibly revised) issue template; a good bug will be minimized, include all relevant context (via your tool, but IMO we can improve it a bit to reduce friction, eg using single cmd, we can discuss this separately)
• nim-bisectbot (bisect bot #8) takes over in the background:
• it gets notified via github API
• parses issue content to extract info it needs (example code)
• verifies validity of the bug otherwise it notifies bug author
• runs git bisect to find 1st offending commit
• notifies author of offending commit
• finds which OS the bug appears on (amongst all CI machines), to check if it's machine specific
• reduces the bug as much as possible, using nim-dustmite (see [TODO] nim-dustmite source code minimization tool for automated bug reduction nim-lang/Nim#8276; it works amazingly well in D, I've saved a ton of time in the past thanks to D's dustmite)

these are basically all the steps that often need to happen (manually) when fixing issues, and all of the above are (with some work) 100% automatable. That leaves only the last step (fixing the actual minimized bug, with all the context now known, ie OS + offending commit).

The last step could be 10% of the work in some cases (and 90% in other cases of course), so it's a huge potential time saver in the long run.

note:

that, while this should work for nim (including other nim projects besides nim repo), most of it could apply to other non-nim github projects, but IMO it's good to have a good working use case first.

note:

any subset of the above task is useful in isolation, so not everything has to work from day 1. In particular, github integration is optional, in which case a human can import the code from a bug into a cmdline tool (say, calling nim-bisectbot from cmdline)