diff options
Diffstat (limited to '.be/bugs')
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 + |