Hacker News Reader

Comment by hungryhobbit | Hacker News Reader

While I like the idea of tool consolidation, bug trackers aren't just a tool for the engineers. At most companies I've worked at, the support team, designers, QA team, managers, etc. all use the bug tracker on a daily basis.

It sounds like you can "bridge" to somehow show the tracker outside Engineering, but then you're having to do work around the consolidation, and I'd imagine the result won't be as nice as a full-featured tracker designed for everyone to use.

But, I am curious to hear from someone who has actually used this thing.

View on HN

Fossil[0] has bug tracking as a standard feature, and through the HTTP role-based authentication, you are able to set up users with different privileges; for instance, being able to read and write the bug tracker without the ability to push new code.

[0]: https://fossil-scm.org/home/doc/trunk/www/index.wiki

+1 for this. I love having a self-contained, syncable GitHub-lite. It uses SQLite for the format, too, which makes it easy to discover the internals.

It just needs some more 'modern' themes

> It uses SQLite for the format

My chance at sharing Fossil is not Relational. The two times it's been submitted to HN it didn't gain votes.

https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...

Thanks for that. I kind of wondered how SQLite was relevant to SCM, but I hadn't really bothered to investigate it. Still, having it in a format that can be browsed and reasoned about is handy. Not that Git is any worse in this regard.

Plus, the only thing I need to do to transfer it to a new disk or network location is to move the `.fossil` file, since everything is nicely self-contained.

hey! maintainer here.

git-bug has a web ui that you can run on your git server, for example, that can be accessed through a browser.

it's fairly limited in functionality right now (create, comment on, and manage issues), but one of my goals is to refactor it to improve coverage of the existing features, and to add support for things like:

- authenticated access

- unauthenticated/anonymous access (e.g. a public, external contributor/user)

- issue privacy levels

- sprints, projects, report generation

Improved user interfaces can always be added on top of the CLI/library functionality, and that’s the more flexible approach. Everyone can use and/or build their favorite UI, like people do with Git itself.

The monolithic web-first (often web-only) systems are a bit of a modern bane, you’re stuck with whatever user interface the one company/maintainer deems appropriate.

It’s expensive to maintain more front ends than you absolutely require. Web+mobile is one too many already.

All those users are why bug trackers are annoying. I don't care about those fields "those other people" are demanding, why do I need to fill them out. Mean while they don't care about the fields that are critical for me and don't want to fill them out.

Every job has a part people don't like that's necessary. The company you work for pays you money to fill the fields out, you fill them out, you get paid.

That's why I do it. That doesn't explain why they even need to be there.

For example every project code drop down has this experience: my manager tells me what project code to put everything against, then I always pick the same option. Sometimes I've not been granted access to that option and waste a bunch of time getting that turned on.

At no point was any part of this necessary, because I neither defined the ticket, or could select the project code for myself, but we're all engaged in an elaborate game pretending I had agency over it.

If you're working somewhere competent then every budget code is an indicator that a manager with a budget has said that they are willing to pay for this piece of work to be done. It may even automatically keep track of how much of their budget was spent on you doing the work.

Or you could show initiative and improve inefficient processes instead of blindly following "how things are done".

There's no I in team...

Or to put it another way, those other 'useless' fields that take minutes may save the company hours of time in places that you don't see.

> There's no I in team...

But there's U and I in unity!

/s aside, you have a valid point there: just because "I" find the field useless, it doesn't mean that it isn't out to actual good use downstream.

More like they justify some middle management busybody's salary.

This is a bug tracker. What you are describing is much closer to a project management tool, just to make the difference clear.

To some people, engineers without project management doesn't make any sense.

Those should be tightly integrated, if not the same tool.

It depends on who manages the project. In an open-source project, those will likely also be engineering types, not non-technical managers.

It's hard to make a product that's all things to all people, and it's wise to make a product that has a well-understood, if more narrow, audience.

I think that is more useful for communities whose members don't have reliable, always-on networks, rather than workflows within companies.

Designers, QA, support and managers are typically already using a VCS, and usually it's Git. And if they don't, this is as good as ever a chance to start.

From QA perspective, which is the one the closest to me: I wanted such a tool for many years, and even though I haven't tried this specific one, I endorse the idea with both of my hands.

In the context of QA, it's always a problem to coordinate between test development, feature development, feature description, and tracking the work progress. All bug trackers I used to date are awful at it. This has a potential to solve at least part of the problem by being physically connected to the work done by either development or QA, or, ideally, both. The holy grail here is the ability to determine what tests to run in response to a commit without making it too much of a burden on the committer.

Tests can easily be the most expensive ongoing activity a development company may undertake. In this context, being able to avoid running useless but expensive tests is very desirable.

Maybe the tool isn't intended for use in commercial environments. There is plenty of work done outside a those environments where this tool might be a better fit. E.g. most free software projects don't have all those other teams interacting with the bug trackers. To put it another way, this seems to fill a similar niche as Github's bug tracker and not Jira.

P.S. The GitHub readme for this project desperately needs a "Why?" (... would anyone use it, ie. what benefits does it offer vs. say Jira?)

I think this is made for an audience who find it obvious. "Why would you do it any other way" would be more interesting: There is a weird divide between git supported features on one hand and pull requests/ merge requests/ patch lists/ issues/ bug trackers etc. If everything was supported in git all these features would be interoperable between forges like github, bitbucket and gitea, forgejo.

Not only interoperability but backups, tooling, distributed workflows and everything in between would work consistently and the same way.

That said, I cannot count the times this concept was brought up and tried to make work but despite how much i love the idea in theory, i have yet to see a way it could work in practice.

Some of the issues: - no universal agreement on exact schema, feature set and workflows, do the competing implementations break each other? if its not interoperable why even bother vs just using an external solution

- how to handle issues not associated to one specific repo or to multiple repos, splitting repos etc.

- how to not confuse devs seeing issue branches or wherever the actual data is stored in the repo

- how to best make this usable to non devs

The list goes on

> "Why would you do it any other way" would be more interesting:

That's the interesting question. Normally a bug tracker would basically be a SQL application. When you move it into a Git repo you lose that and now you have to think about how to represent all that relational data in your repository. It gets annoying. This is why for Fossil it's such a trivial thing to do: Fossil repositories _are_ relational and hosted on an RDBMS (SQLite3 or PG). If you don't have a SQL then referential integrity is easy to break (e.g., issues that refer to others that don't know they're being referred to), and querying your issue database becomes a problem as it gets huge because Git doesn't really have an appropriate index for this.

What one might do to alleviate the relational issues is to just not try to maintain referential integrity but instead suck up the issues from Git into a local SQLite3 DB. Then as long as there are no non-fast-forward pushes to the issues DB it's always easy to catch up and have a functional relational database.

Two corrections:

1. Fossil repositories are explicitly not relational, they are however stored in SQLite databases. The data model for everything SCM-relevant (that also includes all content like tickets, wiki, forum) is stored as artifacts in a blob table (+ delta), which references other artifacts by hash value, and that provides the referential integrity. That, and the code that handles it. There are relations (via auxiliary tables) to speed up queries, but these tables are transient, get updated by inserting new artifacts, and can be regenerated from the artifacts.

(Users and their metadata, and configuration is not part of this scheme, so these tables might be viewed as relational tables. They are local-only; and not synced.)

See https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela... and https://fossil-scm.org/home/doc/tip/www/theory1.wiki for more details.

2. There are no other databases like PostgreSQL to choose from.

I get that the auxiliary tables speed up queries, but the data is relational in nature on some level.

I thought that Fossil did or at least aimed to support different SQL RDBMSes. Did that go away at some point?

Fossil's "file format" is not intimately tied to SQLite: https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki

That being said, it's the only existent implementation and none other are planned. If you'd like to port it to PostgreSQL, go for it, but it probably would lose a lot of the appeal of being a distributed version control system.

I don't think that is the main issue. Its not THAT hard to build a secondary sqlite index for data stored in git and keep in in sync especially because the data is already versioned and can be incrementally updated.

> Normally a bug tracker would basically be a SQL application. When you move it into a Git repo you lose that and now you have to think about how to represent all that relational data in your repository. It gets annoying.

> just not try to maintain referential integrity but instead suck up the issues from Git into a local SQLite3 DB

Applications with SQL backends tackle the problem “how can we express our CRUD datastructures so they fit the relational model?

When you replace SQL with a file-based serialised format, you mainly lose ACID. This is arguably easier than SQL.

You are a single user locally: as long as your IDE plugin doesn’t fight with your terminal client, your need for ACID are low: you handle conflicts like git conflicts, but you may apply domain-specific conflict resolution; while conflicts in source code has no general resolution strategy, merging issue comments can be easy; changing issue status when people agree can be automatically resolved; handling conflicts manually can be tool-assisted.

So losing SQL is not that big of a deal, assuming you’re in a highly decentralised, highly async environment.

The answer to “Why though?” should be forge interop, keeping knowledge in-repo, and because it may fit the organisation (or lack of), e.g. just like you can commit code changes offline, you’re not prevented from updating issues when you’re offline.

> The answer to “Why though?”

I addressed that in a different sub-thread. This one was about "why would you do it any other way?". My commentary about relational data in non-relational media was specifically about why do it any other way. There are great advantages to doing what TFA does -and I acknowledged that in a different sub-thread- but it's still interesting to consider what gets lost, and how to get some of it back.

It's obvious. It's also not original. There are multiple things like this already. Fossil was the first tool to put bug tracking in the repository. Idk which VCS/forge was the first to put wikis in the repository, but it might have been GitHub or Fossil.

The point here is to be able to work with issues, PRs, and wikis offline just as one is now used to doing with code. And to use the same underlying content-addressed version control tooling for all those things.

> Fossil was the first tool to put bug tracking in the repository

I'm pretty sure Aegis did it 15 years before Fossil.

> what benefits does it offer vs. say Jira?

Not being Jira is already a huge benefit. It says offline, local first. Isn't that nice?

Reply on news.ycombinator.com