[arch-general] distributed bugtracking?
anyone knows this? http://bugseverywhere.org/be/show/HomePage the concept looks great, although i don't know anything about the implementation/usage. other then the advantages they list, I think something like this can be useful for downstream<->upstream communication. (ie someone reports a bug in the distro bugseverywhere, they can then more easily forward the bugs to upstream when needed) i blogged about stuff like this @ http://dieter.plaetinck.be/what_the_open_source_community_can_learn_from_dev... if anyone cares. Dieter
Excerpts from Dieter Plaetinck's message of 2010-09-08 21:47:40 +0200:
anyone knows this? http://bugseverywhere.org/be/show/HomePage
the concept looks great, although i don't know anything about the implementation/usage.
other then the advantages they list, I think something like this can be useful for downstream<->upstream communication. (ie someone reports a bug in the distro bugseverywhere, they can then more easily forward the bugs to upstream when needed) i blogged about stuff like this @ http://dieter.plaetinck.be/what_the_open_source_community_can_learn_from_dev... if anyone cares.
Dieter
Hi Dieter, just another distributed bug tracking system: http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki It's also a DVCS and whatnot. What I wonder about is how it compares to git when it comes to the DVCS part. -- Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
On Wed, Sep 8, 2010 at 3:24 PM, Philipp Überbacher <hollunder@lavabit.com> wrote:
Excerpts from Dieter Plaetinck's message of 2010-09-08 21:47:40 +0200:
anyone knows this? http://bugseverywhere.org/be/show/HomePage
the concept looks great, although i don't know anything about the implementation/usage.
other then the advantages they list, I think something like this can be useful for downstream<->upstream communication. (ie someone reports a bug in the distro bugseverywhere, they can then more easily forward the bugs to upstream when needed) i blogged about stuff like this @ http://dieter.plaetinck.be/what_the_open_source_community_can_learn_from_dev... if anyone cares.
Dieter
Hi Dieter, just another distributed bug tracking system: http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
It's also a DVCS and whatnot. What I wonder about is how it compares to git when it comes to the DVCS part.
i don't anything too valuable to add, except that i too have written about this concept, notably here: Distrib -e "Arch(org|code|pkgs|aur|forum|wiki|bugs|.*)?" -- thoughts https://bbs.archlinux.org/viewtopic.php?pid=709188 i think this is the _primary_ barrier affecting uptake of linux/GNU as a mainstream platform. we have all the source, and all the talent, but the heterogeneous nature of OSS (great, but a barrier nonetheless) means we are all using varied and incompatible tools to track/build the same upstreams. we need some unification here, not just for users, but vendors/developers too; such disconnects are a source of serious confusion and duplication of work. i think this, regardless of chosen software, would be a huge step forward. while i haven't released a prototype yet, i am attempting to realize this with work being done on aur-pyjs (https://bbs.archlinux.org/viewtopic.php?id=99839); my "cover" is a replacement for the AUR, but the real motivation behind this project is to build a distribution agnostic platform, a "framework for building linux distributions" if you will. we need to take sources, packages, bugs, software channels (vendors/distributions), and communication (forums/wiki/ML-ish) to the P2P/distributed space, so that all these exobytes of resources can be shared by _all_ communities. DSCM can solve nearly all these problems, including cryptographic verification of origin and identity. specifically, i want to rid ourselves of the notions of versions and packages, and instead move to a "tracking" scheme, ie. aggressive tracking = following HEAD/trunk, stable tracking = following certain tags. we need to eliminate the overhead in packaging, and manual cherry-picking of appropriate versions; i have many specific ideas here, but i don't want to digress too much :-) i wish i had something more tangible to share, but i'm in a bit of a financial crunch, and have only implemented bits and pieces; it is not demo-able yet. however, i am highly motivated to induce/propagate this paradigm shift, so i am responding to encourage everyone to think beyond what is now, and tune your cognitive abilities toward these alternative possibilities. closing the gaps between user/author/vendor/developer/support/etc. means more rapid, consistent, and _transparent_ progression of the entire ecosystem. C Anthony
On Wed, 8 Sep 2010 16:01:43 -0500 C Anthony Risinger <anthony@extof.me> wrote:
On Wed, Sep 8, 2010 at 3:24 PM, Philipp Überbacher <hollunder@lavabit.com> wrote:
Excerpts from Dieter Plaetinck's message of 2010-09-08 21:47:40 +0200:
anyone knows this? http://bugseverywhere.org/be/show/HomePage
the concept looks great, although i don't know anything about the implementation/usage.
other then the advantages they list, I think something like this can be useful for downstream<->upstream communication. (ie someone reports a bug in the distro bugseverywhere, they can then more easily forward the bugs to upstream when needed) i blogged about stuff like this @ http://dieter.plaetinck.be/what_the_open_source_community_can_learn_from_dev... if anyone cares.
Dieter
Hi Dieter, just another distributed bug tracking system: http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
It's also a DVCS and whatnot. What I wonder about is how it compares to git when it comes to the DVCS part.
i don't anything too valuable to add, except that i too have written about this concept, notably here:
Distrib -e "Arch(org|code|pkgs|aur|forum|wiki|bugs|.*)?" -- thoughts https://bbs.archlinux.org/viewtopic.php?pid=709188
some good ideas. i replied at your thread. i think bugseverywhere is more interesting then the other solutions because I think: 1) git > *, or at least git > fossil 2) tracking bugs as close as possible to the actual code (ie. along with the branch) makes most sense. I think the fundamentals are right and the current "deficiencies" seem to come down to lack of some wrapper scripts and maybe a nice (web)interface. At least that's what I gathered from http://lwn.net/Articles/281849/, which is more then 2 years old. They seem to have a basic web interace now, for instance. Dieter
On Wed, Sep 8, 2010 at 12:47 PM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
anyone knows this? http://bugseverywhere.org/be/show/HomePage
the concept looks great, although i don't know anything about the implementation/usage.
There's quite a few things out there with this same idea: - Ditz (http://ditz.rubyforge.org/) - TicGit (http://wiki.github.com/schacon/ticgit/) - git-issues (http://github.com/jwiegley/git-issues) ...etc. I love the idea of distributed bug tracking, but haven't really messed around with too many of them myself to offer more of an opinion. They've been around for a while though. -- Aaron "ElasticDog" Schaefer
On Wed, Sep 8, 2010 at 22:48, Aaron Schaefer <aaron@elasticdog.com> wrote:
On Wed, Sep 8, 2010 at 12:47 PM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
anyone knows this? http://bugseverywhere.org/be/show/HomePage
the concept looks great, although i don't know anything about the implementation/usage.
There's quite a few things out there with this same idea:
- Ditz (http://ditz.rubyforge.org/) - TicGit (http://wiki.github.com/schacon/ticgit/) - git-issues (http://github.com/jwiegley/git-issues)
...etc. I love the idea of distributed bug tracking, but haven't really messed around with too many of them myself to offer more of an opinion. They've been around for a while though.
I've used BE for a tiny little project, but then it was more of a todo-list rather than a proper bugtracker. I'd love to hear from people who've used it in larger projects. As a personal, per-project todo-list manager it was all right. I'm just not still sure whether it should go into the project repo itself, or be standalone. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe
participants (5)
-
Aaron Schaefer
-
C Anthony Risinger
-
Dieter Plaetinck
-
Magnus Therning
-
Philipp Überbacher