3 ms·

I've been using this since I asked HN why BugsEverywhere failed (https://news.ycombinator.com/item?id=20963039 https://news.ycombinator.com/item?id=20963039) ab

by smoyer 7y ago

I've been using this since I asked HN why BugsEverywhere failed (https://news.ycombinator.com/item?id=20963039 https://news.ycombinator.com/item?id=20963039) about six months ago and have to say it's far superior to BE. So far, I haven't found a case where the synchronization to Github didn't work as expected. I also have sensitive repositories that are hosted on Keybase and, since it doesn't include integrated bug tracking, we use Git-bug as a distributed team.

eeZah7Ux 7y ago
BugsEverywhere failed because github killed the distributed aspect of DVCS. The majority of github users do not understand the problem of lock-in. BugsEverywhere is much more lightweight and more mature than git-bug and does not encourage integration with closed-source forges.
- michaelmure 7y ago
  What sort of maturity sign would you like to see?
- theamk 7y ago
  I think BugsEverywhere might have failed because of suboptimal design and lack of features? I have not use BE nor git-bug before, but from looking at the doc pages, git-bug looks way superior. In particular, it looks that by default, BE stores bugs in main repo. Which probably means every comment is a commit, which puts lots of useless entries into the main commit log. (They do mention workflows that store bugs in separate branches.. but this seems undocumented, non-default option) Ironically, I am also not sure how well BE works in the distributed fashion. git-bug has this nice section on how they implemented CRDTs using git, so everyone can comment at once at there are no conflicts. BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project, on some server which handles email submission (how else can one implement debian bugtracker-style email interface?)
  - stephenr 7y ago
    > BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project Literally the first paragraph of the first page about usage in the documentation (https://bugs-everywhere.readthedocs.io/en/latest/tutorial.html#introduction https://bugs-everywhere.readthedocs.io/en/latest/tutorial.ht... ) says exactly what you're talking about: > Bugs Everywhere (BE) is a bugtracker built on distributed revision control. The idea is to package the bug information with the source code, so that developers working on the code can make appropriate changes to the bug repository as they go. For example, by marking a bug as “fixed” and applying the fixing changes in the same commit. This makes it easy to see what’s been going on in a particular branch and helps keep the bug repository in sync with the code.
    - theamk 7y ago
      You have snipped the first part of my message. This is what I said: > git-bug has this nice section on how they implemented CRDTs using git, so everyone can comment at once at there are no conflicts. BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project, on some server which handles email submission (how else can one implement debian bugtracker-style email interface?) So, here is git-bug talking about multiple submissions: [0]. It talks about how to order messages and resolve conflicts in decentralized fashion. Does BE has anything like this? What happens if two people try to claim a bug or change severity to different values? The manual certainly does not tell. When I looked at the bugtracker for BE itself, looks like they don't have any special handling of this, and concurrent PRs will conflict. And for comments, we just use timestamps and don't try to have consistent ordering in any way ( In fact, I think the very next paragraph in your link nicely illustrates how "decentralized" they are. This is what they say: > If you have any problems with BE, you can look for matching bugs: > $ be --repo http://bugs.bugseverywhere.org/ http://bugs.bugseverywhere.org/ list You know that this URL is? This is a primary BE bugs server. It is not using git, hg or any other decentralized protocol -- it is just good old centralized file storage. Even their model -- storing bugs in the main branch -- prevents decentralization, as ability to file bugs (usually granted to everyone) requires ability to commit to master (usually restricted). So yes, they claim things on the page, but they don't expect true decentralized operation, just a one way mirror. [0] https://github.com/MichaelMure/git-bug/blob/master/doc/model.md https://github.com/MichaelMure/git-bug/blob/master/doc/model... [1] https://github.com/kalkin/be/blob/master/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/301724b1-3853-4aff-8f23-44373df7cf1c/values https://github.com/kalkin/be/blob/master/.be/bea86499-824e-4...

by smoyer 7y ago

eeZah7Ux 7y ago

BugsEverywhere failed because github killed the distributed aspect of DVCS. The majority of github users do not understand the problem of lock-in. BugsEverywhere is much more lightweight and more mature than git-bug and does not encourage integration with closed-source forges.

michaelmure 7y ago
What sort of maturity sign would you like to see?
theamk 7y ago
I think BugsEverywhere might have failed because of suboptimal design and lack of features? I have not use BE nor git-bug before, but from looking at the doc pages, git-bug looks way superior. In particular, it looks that by default, BE stores bugs in main repo. Which probably means every comment is a commit, which puts lots of useless entries into the main commit log. (They do mention workflows that store bugs in separate branches.. but this seems undocumented, non-default option) Ironically, I am also not sure how well BE works in the distributed fashion. git-bug has this nice section on how they implemented CRDTs using git, so everyone can comment at once at there are no conflicts. BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project, on some server which handles email submission (how else can one implement debian bugtracker-style email interface?)
- stephenr 7y ago
  > BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project Literally the first paragraph of the first page about usage in the documentation (https://bugs-everywhere.readthedocs.io/en/latest/tutorial.html#introduction https://bugs-everywhere.readthedocs.io/en/latest/tutorial.ht... ) says exactly what you're talking about: > Bugs Everywhere (BE) is a bugtracker built on distributed revision control. The idea is to package the bug information with the source code, so that developers working on the code can make appropriate changes to the bug repository as they go. For example, by marking a bug as “fixed” and applying the fixing changes in the same commit. This makes it easy to see what’s been going on in a particular branch and helps keep the bug repository in sync with the code.
  - theamk 7y ago
    You have snipped the first part of my message. This is what I said: > git-bug has this nice section on how they implemented CRDTs using git, so everyone can comment at once at there are no conflicts. BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project, on some server which handles email submission (how else can one implement debian bugtracker-style email interface?) So, here is git-bug talking about multiple submissions: [0]. It talks about how to order messages and resolve conflicts in decentralized fashion. Does BE has anything like this? What happens if two people try to claim a bug or change severity to different values? The manual certainly does not tell. When I looked at the bugtracker for BE itself, looks like they don't have any special handling of this, and concurrent PRs will conflict. And for comments, we just use timestamps and don't try to have consistent ordering in any way ( In fact, I think the very next paragraph in your link nicely illustrates how "decentralized" they are. This is what they say: > If you have any problems with BE, you can look for matching bugs: > $ be --repo http://bugs.bugseverywhere.org/ http://bugs.bugseverywhere.org/ list You know that this URL is? This is a primary BE bugs server. It is not using git, hg or any other decentralized protocol -- it is just good old centralized file storage. Even their model -- storing bugs in the main branch -- prevents decentralization, as ability to file bugs (usually granted to everyone) requires ability to commit to master (usually restricted). So yes, they claim things on the page, but they don't expect true decentralized operation, just a one way mirror. [0] https://github.com/MichaelMure/git-bug/blob/master/doc/model.md https://github.com/MichaelMure/git-bug/blob/master/doc/model... [1] https://github.com/kalkin/be/blob/master/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/301724b1-3853-4aff-8f23-44373df7cf1c/values https://github.com/kalkin/be/blob/master/.be/bea86499-824e-4...