5 ms·

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,

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.

hungryhobbit 1y ago
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?)
- jFriedensreich 1y ago
  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
  - cryptonector 1y ago
    > "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.
    - Git-Master 1y ago
      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-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela... and https://fossil-scm.org/home/doc/tip/www/theory1.wiki https://fossil-scm.org/home/doc/tip/www/theory1.wiki for more details. 2. There are no other databases like PostgreSQL to choose from.
      - cryptonector 1y ago
        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?
- cryptonector 1y ago
  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.
  - freddie_mercury 1y ago
    > Fossil was the first tool to put bug tracking in the repository I'm pretty sure Aegis did it 15 years before Fossil.
- tasuki 1y ago
  > 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?
hosh 1y ago
I think that is more useful for communities whose members don't have reliable, always-on networks, rather than workflows within companies.
bluGill 1y ago
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.
- baq 1y ago
  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.
  - XorNot 1y ago
    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.
    - AndrewDucker 1y ago
      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.
  - account42 1y ago
    Or you could show initiative and improve inefficient processes instead of blindly following "how things are done".
- pixl97 1y ago
  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.
devrandoom 1y ago
This is a bug tracker. What you are describing is much closer to a project management tool, just to make the difference clear.
- whateveracct 1y ago
  To some people, engineers without project management doesn't make any sense.
- dcrazy 1y ago
  Those should be tightly integrated, if not the same tool.
  - nine_k 1y ago
    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.
chungy 1y ago
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 https://fossil-scm.org/home/doc/trunk/www/index.wiki
- ndegruchy 1y ago
  +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
  - debugnik 1y ago
    > 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-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...
    - ndegruchy 1y ago
      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.
sudoforge 1y ago
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
layer8 1y ago
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.
- baq 1y ago
  It’s expensive to maintain more front ends than you absolutely require. Web+mobile is one too many already.
eikenberry 1y ago
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.
crabbone 1y ago
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.

hungryhobbit 1y ago

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?)

jFriedensreich 1y ago
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
- cryptonector 1y ago
  > "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.
  - Git-Master 1y ago
    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-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela... and https://fossil-scm.org/home/doc/tip/www/theory1.wiki https://fossil-scm.org/home/doc/tip/www/theory1.wiki for more details. 2. There are no other databases like PostgreSQL to choose from.
    - cryptonector 1y ago
      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?
cryptonector 1y ago
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.
- freddie_mercury 1y ago
  > Fossil was the first tool to put bug tracking in the repository I'm pretty sure Aegis did it 15 years before Fossil.
tasuki 1y ago
> 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?

hosh 1y ago

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

bluGill 1y ago

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.

baq 1y ago
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.
- XorNot 1y ago
  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.
  - AndrewDucker 1y ago
    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.
- account42 1y ago
  Or you could show initiative and improve inefficient processes instead of blindly following "how things are done".
pixl97 1y ago
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.

devrandoom 1y ago

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

whateveracct 1y ago
To some people, engineers without project management doesn't make any sense.
dcrazy 1y ago
Those should be tightly integrated, if not the same tool.
- nine_k 1y ago
  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.

chungy 1y ago

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 https://fossil-scm.org/home/doc/trunk/www/index.wiki

ndegruchy 1y ago
+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
- debugnik 1y ago
  > 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-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...
  - ndegruchy 1y ago
    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.

sudoforge 1y ago

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

layer8 1y ago

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.

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

eikenberry 1y ago

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.

crabbone 1y ago

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.