5 ms·

Ask HN: BugsEverywhere was a great idea – why didn't it catch on?

37 points by smoyer 7y ago

The BugsEverywhere (http://docs.bugseverywhere.org/1.1.1/)project has been dormant for a good five years but the idea of including a distributed bug database alongside your code seems like a no-brainer. Several other systems (Fossil, AccuRev, Veracity) include this functionality but I'm wondering why BE didn't catch on with the CLI crowd since it can be layered on top of a variety of SCM systems.

freeone3000 7y ago
Our CI already has a bug tracker. In addition, I think making a commit every time you change bug status (priority, etc) then having to resolve bug database conflicts is less than ideal.
ChristianBundy 7y ago
I think this is a great question. I was originally interested in BugsEverywhere, but noticed that the website linked to a demo at http://bugs.bugseverywhere.org/ http://bugs.bugseverywhere.org/ which was... not a demo. This gave me the impression that the project was completely dead, so I moved on. Recently I've been looking at git-bug, which is similar, but I've been hesitant to use it because the readme talks about how it's alpha software and I'm not super excited about the demo web interface. I'd be interested to hear what others think.
PaulHoule 7y ago
I like the idea of the bug database synchronized with the code base, becoming part of the documentation, but here are my concerns. Often people who are not developers put "issues" into the bug tracker and they might not find working with the command-line easy. If an instance of the system is in use by many, debugging a problem experienced by a particular user might involve personally identifying information which should not be checked in with the source. Also issue trackers sometimes deal with multiple branches of development. In a sane place you might have 4.8 and 4.9 in production and a 5.0-dev, fix a bug in 4.9, then port the fixes to the other branches. To do this you are thinking about the tree as a whole and that's easier done from outside rather than inside the tree.
- flukus 7y ago
  > Often people who are not developers put "issues" into the bug tracker and they might not find working with the command-line easy. IME it's best not to have non-technical people entering bugs, they should be submitting through email, a simple form, automated crash tracker or something along those lines. Most issue trackers will contain so many fields that will make zero sense for someone outside (or even inside) your organisation. They won't know the priority, the won't know the component, they can't find relevant logs to attach, they don't know the internal workflow, they aren't familiar enough to search for similar issues. And that's before you get to the corporate mandated fields, there's some on our issue tracker I don't know, I have no idea if something is capitalizable. Similarly I don't think I've ever put in a successful request to our internal desktop support system, I have no idea what their division of responsibilities are and somehow always select the wrong team. I've become quite religious about creating issues on behalf of people when we get support requests or relevant lunch room chats, otherwise nothing makes it up their side of the corporate org chart and back down ours.
jfkw 7y ago
I also favor issue tracking integrated with the source code and experimented with most of these systems. The first roadblock I noticed to using distributed issue trackers was that the client programs need to be extremely convenient to install on the personal OS and mobile device of everyone involved in the project, something which is very difficult to deliver. A web interface with editing capability could cover some cases, but then you're obliged to host it on a server somewhere.
WorldMaker 7y ago
I'm also someone that fell in love with the concept of issue databases as source control artifacts. I think the biggest problem is always going to be the "Stakeholder" issue, and just about everyone else is touching on this too. Issue databases solve a number of different problems for a number of disparate roles of people. As much time as developers spend embedded in an issue tracker, you also have PMs, Managers, Executives, Clients, Customers, Testers, and sometimes a panoply (or even panopticon) of all sorts of other "stakeholders" with one reason or several to be in and out of an issue database scattered across a wide variety of technical acumen. For anything more than a small team of only technical people, one or more systems of reporting (in either direction) becomes generally required. Can Clients or Customers submit new issues easily? Can PMs (or Managers or Executives) get the reports they need? Can Testers accept issues as completed or file new bugs on them? There's so much more workflow than just the Developer side of things, for better and sometimes for a lot worse. (The "Jira Effect" where nearly every issue tracker eventually seems to succumb to becoming a super-configurable business workflow engine with a built-in CRM and a support desk ticketing system and a hideous kitchen sink with terrible load times.) There's probably still a chance to find a really good sweet spot for distributed issue tracking that has just the right amount of bidirectional reporting to fill an average development team and their stakeholders' needs, but it's probably going to take a smart UX team to do it. A CLI-only approach seems unlikely to work, again just given the huge swath of technical acumen to be found with fingers in an issue tracking pie.
- jacobr 7y ago
  I think code review embedded in git would be more likely to work than issues for this reason.
- viraptor 7y ago
  I'm not sure that's a big issue really. The repository is just a database. You're not forced to work on them manually with the low level tools. There's nothing that would stop you from putting a full blown jira-like UI which interacts with that database. Well... Apart from that UI not existing yet. But in theory, you can have both. With a centralised main head in the same way people use central repository for git.
girishso 7y ago
Distributed databases like git you mean? Even git is no longer used as distributed database, thanks to GitHub.
- quickthrower2 7y ago
  Well it’s still kind of distributed with github because you can still have local branches that differ from the remote.
- CraftThatBlock 7y ago
  Git being "distributed" version control is meant as distributed because it doesn't require a central checkout server, and GitHub is simply a distribution (not checkout) server
  - girishso 7y ago
    Yes absolutely, but I meant the workflows most people use these days (PRs) has turned GitHub into a “central” server.
frou_dh 7y ago
I would posit that the vast majority of working programmers have always-on internet while working. So an offline-capable bug tracker is not actually that much of draw.
- jazzkingrt 7y ago
  Maybe I'm a special case, but once in a while I'm working on a local branch somewhere that doesn't have internet access, like on the subway. I feel this is directionally the same win as the offline capability of a VCS like Git itself. If we have it, we come to expect it. And if someone took it away for some reason, we'd have a better conception of just how useful it can be.
cjbprime 7y ago
Hey, I maintained Bugs Everywhere for a while! For four years starting in 2008. It sure seemed ahead of its time. But also, behind the times in one important way. GitHub has created an expectation that anyone in the world can open an issue against and collaborate with a project. That's incompatible with requiring Git push access to make changes to issues. I created another project -- GitTorrent -- which also tried to increase the decentralization of software production, and this tension of collaboration benefitting from centralized spam fighting and access control mechanisms was there, too. Hopefully one day there'll be magic spam fighting blockchain decentralized identity dust that makes everything work with p2p.
- jazzkingrt 7y ago
  Wouldn't issues get merged in the same way code does -- with a merge request?
  - cjbprime 7y ago
    People are either already on a platform like GitHub, in which case there's an Issues product right there that can be used with much less friction, or they aren't but this idea of "sending a merge request" still feels like anachronism. Joining mailing lists and configuring your SMTP client not to mangle patches seems like an art that everyone just decided to forget how to do. (As an ex-maintainer of the Linux kernel I'm aware that they still do it there. Just.. mostly no-one else.)
    - fragmede 7y ago
      The Git project still does mail-based patch sets! git originated via Linus for the linux kernel, so that's not super surprising.
- ChristianBundy 7y ago
  > Hopefully one day there'll be magic spam fighting blockchain decentralized identity dust that makes everything work with p2p. If you aren't already familiar, you might dig Secure Scuttlebutt. Dat is also in a very similar space.
Izkata 7y ago
There were several others active at around the same time, most with slightly different ideas on how to store the case data. One, for example, handled it with dot files committed as normal - no need to mess with refs. One benefit of that method was that it was truly linked with the code, no need for additional push/pull commands or hooks. This also meant that you could tell the state of a case on a given branch without having to look through commit/merge history - it would become closed on master alongside the code merge. That was also its downside though, since a case could have different comments/status on master vs branches where they started, you had to actually check each branch to see if someone else had already begun or not. Not having a grand centralized view was that one's downfall.
michaelmure 7y ago
Shameless plug warning. I'm the author of git-bug (https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug), a distributed bug tracker actively developed (even a gsoc this summer!). If you are interested by this topic I would very much like you to give it a try or even contribute. git-bug try to improve over the previous iteration of this idea in several ways. To answer your question, those are what I think prevented them to catch on: - it doesn't pollute your project: no files are added alongside your code, no mess during a merge, bugs are stored in your repository but decoupled from your code workflow - it doesn't impose an interface: as you prefer, you can use the CLI tools, the interactive terminal interface or even a webUI. You could also integrate it to your editor, CI system ... - it allows outsider of the project, client, users ... to browse and open bugs, without asking them to install anything. Admittedly, git-bug is not there yet, but the goal is to have the webUI work as a public portal that a project could host easily, accepting authentication from outside system (github OAuth ...).
nairobi222 7y ago
I like the idea of the bug database synchronized with the code base, becoming part of the documentation, but here are my concerns. Often people who are not developers put "issues" into the bug tracker and they might not find working with the command-line easy. If an instance of the system is in use by many, debugging a problem experienced by a particular user might involve personally identifying information which should not be checked in with the source. Also issue trackers sometimes deal with multiple branches of development. In a sane place you might have 4.8 and 4.9 in production and a 5.0-dev, fix a bug in 4.9, then port the fixes to the other branches. To do this you are thinking about the tree as a whole and that's easier done from outside rather than inside the tree.

shoo 7y ago

> I'm not sure that's a big issue really. The repository is just a database. in large non-tech companies i see a pattern where the company adopts standard open source tools arguably better suited to open source distributed development (many small git repos, github/gitlab) -- but then there can be pressure to present information for ease of central governance and control at $current_job there's pressure for 100-200 people to use a single jira project so auditing and risk can be done via that one jira project, whereas at the same time there are an increasing number of git repos containing code for different systems (or ci/cd/build scriptery for different systems) the jira project everyone is forced to use has about 100 different states a ticket can be in (many synonyms) and about 30 different custom relationships defined between pairs of tickets - so it is challenging to sanely encode or track the state of tickets (lowest-common-denominator meaning that it cannot be a fair approximation of the reality of an individual team's process) while also being absurdly slow. i am not quite sure what my take away is but it is completely non obvious how putting the issue tracking db in a single git repo would materially help any of this. a sufficiently entrenched bureaucracy can destroy the value of any technology...

viraptor 7y ago
> but it is completely non obvious how putting the issue tracking db in a single git repo would materially help any of this I think it could actually prevent bureaucracy from destroying the value. They can have whatever reporting, enforced flows, business states, etc that live in the repo. You get all of that info locally - so you can create a minimal, lean interface for only the small part of it that matters to you. One of the problems I had with JIRA where I used it was that it grew into a monster, even though I only needed maybe 3 functions out of it. It could be simplified from my side, but... the API was not exposed because corporate rules and the number of requests that would require to enable, made it useless to try.