--- /dev/null
+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.
+
projects / be.git / commitdiff