3 ms·

BugsEverywhere failed because github killed the distributed aspect of DVCS. The majority of github users do not understand the problem of lock-in. BugsEverywhe

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...
    - stephenr 7y ago
      > So, here is git-bug talking about multiple submissions: [0]. It talks about how to order messages and resolve conflicts in decentralized fashion. This is the part that seems to sum that whole page up: > When pulling bug updates from a remote, we will simply add our new operations (that is, new Commits), if any, at the end of the chain. Which indicates it's just changing a value without any indication to you that you changed what someone else wrote. I'm not so arrogant as to claim that is what happens just from reading some text on a page, so I'd love for someone more experience with this tool to clarify how a "multiple edits of the same attribute" event flow plays out. > Does BE has anything like this? What happens if two people try to claim a bug or change severity to different values? They're just files in the repo, so conflicting changes behave exactly the same way changes in git or hg or whatever do: you have to resolve the conflict. > 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. BE has the ability to query a remote bug repo without the need for cloning the entire git/hg/whatever-vcs/no-vcs repo it's hosted in. That's what you're seeing there. But hey good for you on a ridiculous rant based on misunderstanding something. Have a gold star. > Even their model -- storing bugs in the main branch ... bugs are stored in a directory, and versioned like regular files. The entire point being that as you make a change to the code in a branch, when finished you can also close the bug in that branch. When merged, that bug is now closed. I don't know whether you just didn't read anything about BE, or you're deliberately making shit up to troll, but your claims are wildly inaccurate.

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...
  - stephenr 7y ago
    > So, here is git-bug talking about multiple submissions: [0]. It talks about how to order messages and resolve conflicts in decentralized fashion. This is the part that seems to sum that whole page up: > When pulling bug updates from a remote, we will simply add our new operations (that is, new Commits), if any, at the end of the chain. Which indicates it's just changing a value without any indication to you that you changed what someone else wrote. I'm not so arrogant as to claim that is what happens just from reading some text on a page, so I'd love for someone more experience with this tool to clarify how a "multiple edits of the same attribute" event flow plays out. > Does BE has anything like this? What happens if two people try to claim a bug or change severity to different values? They're just files in the repo, so conflicting changes behave exactly the same way changes in git or hg or whatever do: you have to resolve the conflict. > 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. BE has the ability to query a remote bug repo without the need for cloning the entire git/hg/whatever-vcs/no-vcs repo it's hosted in. That's what you're seeing there. But hey good for you on a ridiculous rant based on misunderstanding something. Have a gold star. > Even their model -- storing bugs in the main branch ... bugs are stored in a directory, and versioned like regular files. The entire point being that as you make a change to the code in a branch, when finished you can also close the bug in that branch. When merged, that bug is now closed. I don't know whether you just didn't read anything about BE, or you're deliberately making shit up to troll, but your claims are wildly inaccurate.