Hacker News Reader

Comment by BiteCode_dev | Hacker News Reader

I'd like to have a serverless bug tracker, like Fossil, but for git.

Basically a bug tracker that stores the whole DB in the git repo but separately from the main tree. The tickets get synced when I push/pull, I can interact with them locally without needing an internet connection, without having to filter out projects, authenticate, etc. An open ticket would have my current branch/tag/commit as a default value for tracking, although it could be change.

And I really, really don't want notifications. Just a dashboard where the last things that are important to me are listed as long as I haven't marked them as read, and an access history.

But you can't make money with that I guess.

View on HN

There's https://github.com/MichaelMure/git-bug (I haven't tried it out yet, but looks very promising).

You are my hero today.

EDIT: just tried it, still very basic, but already does the job for a small project. I'm considering contributing.

Yes please :)

Edit: consider having a look at the development version. While the core feature hasn't changed much, the webUI definitely improved. Also, the core became more robust and ready to accept more features easily.

Working with it for some years already. Recently the UI part got much better, but the console part with or without bridge is good enough already.

Not very promising, it is written in a language which:

- is controlled by Google.

- doesn't support generics. Do we really want people to constantly rewrite basic data structure classes in 2021 and thereby reinvent bugs constantly (and waste time which could be spent on more meaningful purposes)?

Damn, these are some stupid arguments. Go is open source. Even if Google went rogue, there's nothing they could do. Go would just get forked by the community and that's it. As for generics, they're just nothing more than a developer convenience, they don't matter at all regarding what a product can do. Also they're planned in Go for next year.

> Go is open source. Even if Google went rogue, there's nothing they could do.

Have you ever used a library where the company who paid the development went "whoops, not our product anymore! poof goes the paid team, website, the community forums, the knowledgebase" ?

Usually nobody continues to maintain these after 90% of the workforce behind them gets fired and the surrounding infrastructure disappears.

Software is almost worthless without the brains behind it.

> As for generics, they're just nothing more than a developer convenience,

So you propose people write the 100,000th implementation of linked lists, maps, etc. because what they want to stick into it is not class A but class B?

> Also they're planned in Go for next year.

The fact it took years to plan them instead of including them right away is a nice proof of how ill-conceived Go is as a language.

It might have been nice as a toy to teach aspiring programmers. It shouldn't have ended up in production software.

> Damn, these are some stupid arguments.

Thanks. I consider yours as stupid too. How much progress exactly have we achieved with this wording now?

It's pretty clear you're trolling now, but FWIW:

- slices and maps are already generic in Go

- Go has great performance, great readability and write ability, and that's valuable for everyone, not just beginners

- Go is a language, not a library

> The fact it took years to plan them instead of including them right away is a nice proof of how ill-conceived Go is as a language.

It's not. Really.

> It's pretty clear you're trolling now

I am not. I genuinely think Google is evil and should be dismantled.

> - slices and maps are already generic in Go

So people are supposed to not rewrite 2 of the possibly infinite types of data structures and classes, and constantly rewrite all the rest of them?

> - Go has great performance, great readability and write ability, and that's valuable for everyone, not just beginners

Enough other languages do as well.

> Go is a language, not a library

If Google abandons the funding it does not matter what it technically is. No money, no developers.

I don't care, I want to use it not dev in it.

If the people working for free to give me FOSS are happy with this stack, more power to them. No complaining.

So anything made by tech controlled by a big corp is not promising?

We should not use Go, Java, C#, Angular, React, Objective-C, Swift, Kotlin, Dart, .... ?

Neither of those criticisms pertain to the actual product itself. Go is a tried and tested product, used daily in critical infra and is FOSS

You are absolutely right! And this is why I avoid any and all software written in C due to AT&Ts prior evil monopolistic practices of the mid-20th century. /s

For interest sake: what language carries your blessing instead?

There are a number of tools for distributed bug tracking:

https://news.ycombinator.com/item?id=22833037

Yes but all those tools share one common problem: they leak their implementation or want to do too much.

The ruby one ask to gem install, the python one to pip install, the one in bash assumes Unix, the one in perl tells you to "make install" (!), radicle wants to replace my entire stack.

As a Python dev, I don't want to ask my front end experts or worse, my testing team, to setup an entire python env just so they can fill tickets. I just want to donwload an executable, and then fill in my tickets.

gitbug gives us binaries. You just execute it, and you are good to go.

Maybe one day, Python devs will take the time to use nuitka to produce binaries for their users.

Since no one else said it, why not just use Fossil? It's precisely what you want already, and it's well made.

a git based bug tracker, thats a new one!

But it does make sense. Can be offline, will be redundant and fast (as its local).

Question is how many folks out there will be at home with this?

We really thought the platform nudges (compared to a PM following up) would make a difference...Why don't you want notifications?

Because as a dev, my attention is precious. To be productive, I prefer to pull information, than to be pushed information to.

E.G: HN doesn't push information on me. I can answer to you now because I know that at this very moment, I don't need to focus on something hard. But this afternoon, I will, and so I don't want to be disturbed and will just close this tab. Voilà, no distraction.

I don't need to be notified bugs: I don't work on them in real time. In the morning, I select the ones I will work on. New ones have little relevance to me until the next morning, which a dashboard will show me.

I need notifications on things like my clients calling me or my server failing. Those are the stuff that I need in real time.

The very first thing I do when registering with a new service, especially corporate/social ones is to go to the notification settings and disable everything but the direct message stuff.

I leave them enabled but email only, then I set up filters for each service to move it to */automated/jira directories automatically.

That way my inbox stays clear but I can speed run through first thing to make sure I’ve not missed anything, I also ruthless cull anything unrelated to my work, so any notification a project I don’t work on gets deleted.

This reduces several thousand emails a month to about 6 I actually need to see in my inbox.

The default is insanity though I agree.

Makes sense. The PM and the tester might want the devs to be notified, but as devs that does break our focus.

Thanks for point this out, this will help us rethink 'nudges'.

Reply on news.ycombinator.com