Commented on 12c: Bug aggregation. Multi-repo meta-BE?

2 files changed, 91 insertions, 0 deletions

diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body
new file mode 100644
index 0000000..e7b48e0
--- /dev/null
+++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body
@@ -0,0 +1,83 @@
+I read
+  http://weblog.masukomi.org/2008/1/3/distributed-bug-tracking
+yesterday, and the section on bug visibility got me thinking about
+bug 12c (Multi-repo meta-BE?) some more.
+
+We already have interfaces like this email/html mashup:
+
+On Sun, Sep 13, 2009 at 07:04:05AM -0400, W. Trevor King wrote:
+> Since the non-bzr interfaces to BE are coming along nicely, I've put
+> up a non-bzr interface to my be-rr branch.
+>   http://www.physics.drexel.edu/~wking/code/be
+> It uses nightly builds of Gianluca's static html from my devel branch
+> to provide read-only browsing, and accepts changes from the general
+> public through my email interface into a public branch.  I handle the
+> synchronization of these two branches manually.
+
+These interfaces provide a means for remote users to access a BE
+repository without bzr or the command line.  As far as users are
+concerned, this exposed repository looks pretty much like a
+centralized bugtracking system (e.g. bugzilla, ...).
+
+However, with BE we have more bug information living off in other
+branches that haven't yet been merged with the exposed repo.  The
+problem is two-fold:
+  1) how to keep up to date within a distributed community.
+  2) how do users find branches/patches that fix bug XYZ.
+
+For (2), I think the best solution at the moment are along the lines
+of my little scripts (discussed in the bug 12c comments).  With the
+addition of the `be diff --dir DIR` option, it's now even easier to
+find more information on bug 565 (or whatever UUID):
+  be/be.wtk$ for repo in ../*; do \
+              if [ $repo == "be.wtk" ]; then continue; fi; \
+              diff=$(be diff --dir $repo --subscribe 565:all); \
+              if [ -n "$diff" ]; then \
+                echo "Changed from $repo:"; echo "$diff"; \
+              fi; \
+             done
+  Changed from ../be.html:
+  New bugs:
+    565:fm: be email-bugs for bug submission from bzr-less users
+  Changed from ../be.trunk:
+  New bugs:
+    565:fm: be email-bugs for bug submission from bzr-less users
+  Changed from ../cherryflavoredbugseverywhere:
+  New bugs:
+    565:fm: be email-bugs for bug submission from bzr-less users
+where the --dir and --subscribe options to `be diff` are new.  If
+people don't like the command line, this would be easy to bundle into
+a web-frontend (CFBE?) if you wanted, with a cron job pulling updates
+into the tracked branches.
+
+I was starting into a solution for (1) when I did this:
+
+On Mon, Jul 27, 2009 at 08:42:19AM -0400, W. Trevor King wrote:
+> My email interface now supports subscription:
+>   be subscribe DIR       # see any changes to the bug directory.
+>   be subscribe BUG-ID    # see changes to a particular bug.
+> See
+>   be subscribe --help
+> for more details.
+
+The idea was that a dev/user would subscribe to whatever issues they
+wanted to track, and they would get email notifications whenever some
+action affected any of those issues.  These subscriptions would
+percolate through the distributed branches as a result of the usual
+mergers.  For example, my subscription to all changes has made it into
+the trunk branch (see .be/settings).
+
+This subscription mechanism was setup to work through interactive
+public interfaces (my email interface, eventually CFBE, ...), but
+it doesn't work for changes made via the command-line interface,
+so I browsed around a bit and ran across some interesting workflows
+in the bzr documentation
+  doc/developers/HACKING.txt, "Communicating and Coordinating"
+which points out the following plugins
+  * email (http://doc.bazaar-vcs.org/plugins/en/email-plugin.html)
+  * dbus (http://doc.bazaar-vcs.org/plugins/en/dbus-plugin.html)
+which send automatic notification messages after commits, etc.  If
+people want this sort of functionality, it would be easy enough to rig
+a hook for `be commit' that sent a diff email to subscribers, which
+could include be-devel.
+
diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values
new file mode 100644
index 0000000..adb1ae5
--- /dev/null
+++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values
@@ -0,0 +1,8 @@
+Author: W. Trevor King <wking@drexel.edu>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 05 Dec 2009 22:39:07 +0000
+