1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
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.
|
