monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: Announce: DisTract - Distributed Bug Tracker based


From: Bruce Stephens
Subject: [Monotone-devel] Re: Announce: DisTract - Distributed Bug Tracker based on Monotone
Date: Tue, 24 Apr 2007 13:38:49 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux)

Matthew Sackman <address@hidden> writes:

[...]

> Not just with the general disconnect operation either, but for
> example, with policy branches: it may well be possible to prevent a
> "code" branch being merged back into the main trunk or "release"
> branch unless the "bug" branch corresponding to that code has no
> open bugs. That kind of thing. I hope that there are some very cool
> and useful possibilities that I've not thought of at all yet.

Also true.  Those could also be done by referencing bugids in certs, I
suspect.

As a concrete example, at work (not that anyone has any reason to
care, but that's Isode Limited) we do almost all integrations only
after code review.

Code review involves a change report (a CR), which is just a text file
that lists a bunch of things about the change, one of which is a list
of bug ids, if this CR is fixing bugs.

When the code's committed, the CR id ends up as part of the changelog.
So when we prepare the release notes we can check to see which bugs
may have changed status for that release (and then we can check
bugzilla to see if they've been closed).  So although just looking at
bugzilla's not good enough (the bug may have been fixed only on a
different branch), nevertheless we don't need to just rely on that.

Using monotone, one could use a cert for the same purpose.

(As an aside we keep these CRs under version control, and that
provides (as far as I can tell, anyway) virtually no benefit in
itself, in that we don't use branches for them and (as far as I know)
nobody ever looks at previous versions of a CR.  (That may be because
of an implementation flaw, however: we don't store the to-be-reviewed
code changes, and seeing changes in *that* might occasionally provide
value.))




reply via email to

[Prev in Thread] Current Thread [Next in Thread]