Merge large rework from W. Trevor King.

37 files changed, 1255 insertions, 0 deletions

diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body
new file mode 100644
index 0000000..fa9e963
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body
@@ -0,0 +1,36 @@
+* W. Trevor King (wking@drexel.edu) wrote:
+> One problem is that we don't actually have "releases".  People just
+> clone a branch, install, and go.
+
+  This is actually the main reason I've manually mirrored the tree in
+the past, so that users of our projects can get BE.  If tarballs were
+available I probably wouldn't even bother, but bzr really isn't a nice
+dependency for just submitting/commenting on bugs.
+
+  Isn't there a bzr web interface that at least supports creating
+tarballs/zips?  It is pretty standard functionality for most other VCS'
+web interfaces so I'm guessing there must be, but loggerhead seems not
+to support it.
+
+  If it is a case of not having the hardware to host a more featureful
+web UI I may be able to offer some assistance.
+
+> If you're worried about stability, just clone from a more stable branch
+> (i.e., Chris' trunk).  I think > this is good for distributed development,
+> but maybe makes it hard to package into a conventional release-based system.
+> With the bzr patch number in setup.py as the patch release number, I would be
+> releasing my 0.1.363 while Chris releases his 0.1.314, even though they're at
+> about the same point.  I would rather be releasing my
+>   0.1.20090714121347
+> while Chris releases his
+>   0.1.20090713154540
+> Since then the similarity is clearer.
+
+  Both approaches seem pretty odd to me, as a user you would have no
+idea if 0.1.200910302359 has the fixes you required in a release you
+were using that was numbered 0.1.200907141554.  Surely you'd at least be
+{pre,suf}fixing a branch name to the version.
+
+Thanks,
+
+James
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values
new file mode 100644
index 0000000..c064938
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values
@@ -0,0 +1,14 @@
+Alt-id: <20090714142942.GA5717@ukfsn.org>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 15:29:42 +0100
+
+
+From: James Rowe <jnrowe@gmail.com>
+
+
+In-reply-to: ea01c122-e629-4d5c-afa7-b180f4a8748b
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body
new file mode 100644
index 0000000..7e1434b
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body
@@ -0,0 +1,115 @@
+On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote:
+> * W. Trevor King (wking@drexel.edu) wrote:
+> > One problem is that we don't actually have "releases".  People just
+> > clone a branch, install, and go.
+> 
+>   This is actually the main reason I've manually mirrored the tree in
+> the past, so that users of our projects can get BE.  If tarballs were
+> available I probably wouldn't even bother, but bzr really isn't a nice
+> dependency for just submitting/commenting on bugs.
+
+Fair enough.  It will be good when we get a commit-able web interface
+and/or email interface going.
+
+>   Isn't there a bzr web interface that at least supports creating
+> tarballs/zips?  It is pretty standard functionality for most other VCS'
+> web interfaces so I'm guessing there must be, but loggerhead seems not
+> to support it.
+
+Unfortunately, people would still need bzr to install the versioned source:
+
+  libbe/_version.py:
+          bzr version-info --format python > $@
+
+So you'll need a "release" target in the makefile to build a bzr-less
+install.  While you're at it, you should probably compile the manpage
+too to remove the docbook-to-man dependency.
+
+Do people want a HEAD tarball too?  There must be a bzr equivalent of
+  .git/hooks/post-update
+but I don't know what it is.
+
+> > If you're worried about stability, just clone from a more stable branch
+> > (i.e., Chris' trunk).  I think > this is good for distributed development,
+> > but maybe makes it hard to package into a conventional release-based system.
+> > With the bzr patch number in setup.py as the patch release number, I would be
+> > releasing my 0.1.363 while Chris releases his 0.1.314, even though they're at
+> > about the same point.  I would rather be releasing my
+> >   0.1.20090714121347
+> > while Chris releases his
+> >   0.1.20090713154540
+> > Since then the similarity is clearer.
+> 
+>   Both approaches seem pretty odd to me, as a user you would have no
+> idea if 0.1.200910302359 has the fixes you required in a release you
+> were using that was numbered 0.1.200907141554.  Surely you'd at least be
+> {pre,suf}fixing a branch name to the version.
+
+"be --version" currently gives you the revision id:
+  wking@drexel.edu-20090714121347-c6rloikst1t3m5yl
+which tells you exactly which commit your installed version is based on.
+If we want stick with revision numbers, how about:
+  major.minor.revno-branch_nick
+But then we'd have to pick "unique" branch nicknames...
+
+I'd sliced out the timestamp portion of the revision id so that the
+"patch-number" would be an integer and the branch name wasn't
+references, so that "upgrading" from one branch to another could be
+transparent to the users (who just see an increading timestamp), but
+still available to the developers (who know when commits were made to
+the branches they track, and the likelyhood of to-the-second commit
+collisions in official packages is small).
+
+On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> "W. Trevor King" <wking@drexel.edu> writes:
+> 
+> > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > > Please, no. Timestamps aren't version strings, that's conflating two
+> > > pieces of information with very different meanings. Correlating the
+> > > two is the job of a changelog.
+> > 
+> > Which we don't bother keeping (also NEWS), since "bzr log" works so
+> > nicely.
+> 
+> That's not a changelog, that's a commit log of every source-level commit
+> made. Far too much detail for a changelog of *user-visible* changes
+> associated with a release.
+
+I need a user around to help me determine "user-visable" changes ;).
+My labmates loose interest after be init/new/comment :p.  None of
+which has ever changed, other than set-root -> init ;).
+
+> > The timestamp should at least replace the patch release number, which
+> > you agree is-desirable-to increase motonically ;).
+> 
+> I still disagree that a timestamp is the right thing to use there. If
+> you want a monotonically-increasing indicator of which revision we're up
+> to, that's immediately available with the revision number from VCS on
+> the main branch. That also has the advantage of producing consecutive
+> numbers for each revision, by definition.
+
+But not during branch-switches, while my method skips large regions,
+but probably increases during any reasonable branch-switch.  For
+example, when I upgraded to rich root to pull Ben's patch, I'm not
+sure if Chris upgraded the trunk and merged my branch, or just ditched
+the trunk and cloned my branch.  Using actual bzr revision numbers
+would make switching branches that either wrong (in the case of
+rev-id decreases) or confusing (in the case of a single
+non-consecutive increase).
+
+On Tue, Jul 14, 2009 at 11:11:31AM -0400, Chris Ball wrote:
+>    > I agree that's a problem. I think the solution is to start making
+>    > releases, with specific version strings, as source tarballs.
+> 
+> I'm happy to do this if people think it would be useful, and I don't
+> yet have a strong opinion on whether the releases should come with
+> version numbers or timestamps.
+
+I imagine the news from 2006 to now will be somewhat abridged ;).
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values
new file mode 100644
index 0000000..4538a9f
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values
@@ -0,0 +1,14 @@
+Alt-id: <20090714171725.GB10445@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 13:17:25 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 0c40c13a-3515-4b45-a8c3-142cceab9254
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body
new file mode 100644
index 0000000..a0b6a14
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body
@@ -0,0 +1,58 @@
+Chris Ball <cjb@laptop.org> writes:
+
+> Hi,
+> 
+>    > That's not a changelog, that's a commit log of every source-level
+>    > commit made. Far too much detail for a changelog of
+>    > *user-visible* changes associated with a release.
+> 
+> I think I agree with both of you. :) It seems like it's both true that
+> there's no point in keeping a GNU-style ChangeLog these days
+
+I think I have a better understanding of why this apparent disagreement
+occurred, and it was due to my sloppy use of terms.
+
+Looking into it further, it seems there is a certain expectation (set,
+in part, by the long-standing GNU coding conventions) that a “GNU-style
+ChangeLog” contains not only a particular *format*, but information at
+a particular level of *detail*.
+
+That is, a GNU ChangeLog is intended for the style of work where one
+logs all the changes made to every file in the tree each working day,
+and then makes a new day's entry above that, and so on. This is, of
+course, entirely redundant with a VCS revision history, which makes all
+the commit messages available on request.
+
+So to disambiguate, that's not what I meant. I'm more familiar with a
+less-frequently-updated and less-fine-detail change log; perhaps more
+akin to the GNU-style “NEWS” file.
+
+> and that if we make a release we should write an announce mail that
+> directly mentions new user-visible changes as well as attaching the
+> commit log. That smaller list of highly user-visible changes could
+> live in NEWS, or in the announce mail, or both.
+
+Yes, that's mostly what I meant.
+
+I actually don't think the commit log needs to be part of the release at
+all. It's of interest only to those who want fine-level detail about
+changes to every file, and for that purpose I think read access to the
+VCS is much better. Packaging a static copy of the commit log as plain
+text seems pointless.
+
+Rather, we should treat a user-changes level “NEWS” file (or whatever
+name we choose for it) as part of the documentation, and set the
+expectation among the team that it will be updated for each user-visible
+change being worked on, like any other documentation.
+
+-- 
+ \            “… Nature … is seen to do all things Herself and through |
+  `\         herself of own accord, rid of all gods.” —Titus Lucretius |
+_o__)                                                 Carus, c. 40 BCE |
+Ben Finney
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values
new file mode 100644
index 0000000..4e3ade1
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values
@@ -0,0 +1,14 @@
+Alt-id: <87hbxdhtkp.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 16 Jul 2009 19:21:10 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body
new file mode 100644
index 0000000..5f478b5
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body
@@ -0,0 +1,96 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+W. Trevor King wrote:
+> Thinking about this some more, I think that the role of the
+> main-branch is to officially sanction the current state of the code as
+> "released".  If a series of commits will leave a branch in a
+> known-unusable form, they should be carried out in some appropriately
+> named development branch.  Then the log of commits to the main branch
+> ("bzr log -n 1" for bzr > ) should produce a fairly respectable
+> changelog.
+
+This is how we develop bzr itself.  The mainline is controlled by PQM,
+which is a tool that merges feature branches, runs the tests, and
+commits only if the tests pass.
+
+$ bzr log --short --limit 10
+ 4534 Canonical.com Patch Queue Manager	2009-07-14 [merge]
+      (abentley) Implement merge --interactive
+
+ 4533 Canonical.com Patch Queue Manager	2009-07-14 [merge]
+      (jml) Merge in changes from 1.17 branch.
+
+ 4532 Canonical.com Patch Queue Manager	2009-07-14 [merge]
+      (igc) zc.buildout Windows build support (Sidnei da Silva)
+
+ 4531 Canonical.com Patch Queue Manager	2009-07-13 [merge]
+      (vila) Delete forgotten debug print
+
+ 4530 Canonical.com Patch Queue Manager	2009-07-13 [merge]
+      (vila) Isolate some tests from TZ
+
+ 4529 Canonical.com Patch Queue Manager	2009-07-13 [merge]
+      (igc) Bazaar 2.0 Upgrade Guide
+
+ 4528 Canonical.com Patch Queue Manager	2009-07-13 [merge]
+      (mbp) correction to news
+
+ 4527 Canonical.com Patch Queue Manager	2009-07-13 [merge]
+      (jml) Merge in 1.17 branch, updating version numbers and NEWS file.
+
+ 4526 Canonical.com Patch Queue Manager	2009-07-10 [merge]
+      (mbp, vila) Finish the *_implementation to per_* test renaming
+
+ 4525 Canonical.com Patch Queue Manager	2009-07-10 [merge]
+      (vila) Quicker check for changes in mutable trees
+
+You can also see all the merges as they come into the mainline:
+
+$ bzr log --short --limit 10 --include-merges
+ 4534 Canonical.com Patch Queue Manager	2009-07-14 [merge]
+      (abentley) Implement merge --interactive
+
+      4526.6.15 Aaron Bentley	2009-07-14
+                Update command help
+
+      4526.6.14 Aaron Bentley	2009-07-14
+                Use default DiffWriter.
+
+      4526.6.13 Aaron Bentley	2009-07-14
+                Add docstring to do_interactive.
+
+      4526.6.12 Aaron Bentley	2009-07-14
+                Updates from review.
+
+      4526.6.11 Aaron Bentley	2009-07-13
+                Update NEWS.
+
+      4526.6.10 Aaron Bentley	2009-07-13 [merge]
+                Merged apply-vocab into merge-interactive.
+
+           4526.7.4 Aaron Bentley	2009-07-13 [merge]
+                    Merged bzr.dev into apply-vocab.
+
+       4526.6.9 Aaron Bentley	2009-07-13 [merge]
+                Merged apply-vocab into merge-interactive.
+
+           4526.7.3 Aaron Bentley	2009-07-13
+                    Test shelve_change.
+
+> This also means that _every_commit_ to a main branch would
+> be an official release.
+
+We don't do that.  We have official releases every 4 weeks, but we do
+believe that running bzr.dev is pretty safe, because it's always tested
+and our test suite is quite thorough.
+
+Aaron
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.9 (GNU/Linux)
+Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
+
+iEYEARECAAYFAkpcznIACgkQ0F+nu1YWqI0yhACePTFUUp6u+Dw+8IRwWOWBQRtb
+TgsAniJq4lqnDfjNACMr7IEt7xYJhx7m
+=BbGG
+-----END PGP SIGNATURE-----
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values
new file mode 100644
index 0000000..5134cf2
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values
@@ -0,0 +1,14 @@
+Alt-id: <4A5CCE76.9040106@aaronbentley.com>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 14:29:10 -0400
+
+
+From: Aaron Bentley <aaron@aaronbentley.com>
+
+
+In-reply-to: ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body
new file mode 100644
index 0000000..b34e037
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body
@@ -0,0 +1,52 @@
+On Tue, Jul 14, 2009 at 07:34:04PM +0100, jnrowe@gmail.com wrote:
+> [This time to the list]
+> 
+> * W. Trevor King (wking@drexel.edu) wrote:
+> > On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote:
+> > >   Isn't there a bzr web interface that at least supports creating
+> > > tarballs/zips?  It is pretty standard functionality for most other VCS'
+> > > web interfaces so I'm guessing there must be, but loggerhead seems not
+> > > to support it.
+> > 
+> > Unfortunately, people would still need bzr to install the versioned source:
+> > 
+> >   libbe/_version.py:
+> >           bzr version-info --format python > $@
+> 
+>   I hadn't even seen that change go in.  The last upstream change in the
+> version I have installed locally was by you on 2008-11-24.
+
+It's only been in Chris' http://bzr.bugseverywhere.org/be/ branch
+since revno: 321, 2009-06-25.  Obviously we may have to adjust the
+--verison output once we settle on a versioning scheme, but whatever
+we pick, I think having the auto-generated libbe/_version.py around
+for pinpointing bugs is worth the trouble of requiring bzr when
+building distribution tarballs.
+
+> > So you'll need a "release" target in the makefile to build a bzr-less
+> > install.  While you're at it, you should probably compile the manpage
+> > too to remove the docbook-to-man dependency.
+> 
+>   Maybe for others.  Our packages just don't have the manpage as it is only
+> the "be help" text reformatted, the easy option is sometimes the right
+> one :)  Also, I've just noticed that it has even less documentation in
+> the bzr tree[1] making its installation much less compelling unless your
+> packaging rules require a man page like Debians.
+> 
+>   Out of curiosity why is the Makefile being used for this stuff anyway?
+> It is going to make it difficult to build locally when we finally get
+> around to merging.  Examples: If distutils was being used exclusively it
+> would fix the #! lines in xml/*.  We'd be able to point Python
+> $version_of_the_day at setup.py instead of having to sed the Makefile or
+> run setup and manually install other files.
+
+I speak Makefile better than I speak distutils ;).  I'm not sure how
+to translate the be.1 generation/installation or the libbe/_version.py
+generation into distutils.  Anyone else?
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values
new file mode 100644
index 0000000..0c1e529
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values
@@ -0,0 +1,14 @@
+Alt-id: <20090714191145.GB10606@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 15:11:45 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 6e315abe-a080-4369-8729-4aea2dee8494
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body
new file mode 100644
index 0000000..7ffe231
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body
@@ -0,0 +1,38 @@
+[This time to the list]
+
+* W. Trevor King (wking@drexel.edu) wrote:
+> On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote:
+> >   Isn't there a bzr web interface that at least supports creating
+> > tarballs/zips?  It is pretty standard functionality for most other VCS'
+> > web interfaces so I'm guessing there must be, but loggerhead seems not
+> > to support it.
+> 
+> Unfortunately, people would still need bzr to install the versioned source:
+> 
+>   libbe/_version.py:
+>           bzr version-info --format python > $@
+
+  I hadn't even seen that change go in.  The last upstream change in the
+version I have installed locally was by you on 2008-11-24.
+
+> So you'll need a "release" target in the makefile to build a bzr-less
+> install.  While you're at it, you should probably compile the manpage
+> too to remove the docbook-to-man dependency.
+
+  Maybe for others.  Our packages just don't have the manpage as it is only
+the "be help" text reformatted, the easy option is sometimes the right
+one :)  Also, I've just noticed that it has even less documentation in
+the bzr tree[1] making its installation much less compelling unless your
+packaging rules require a man page like Debians.
+
+  Out of curiosity why is the Makefile being used for this stuff anyway?
+It is going to make it difficult to build locally when we finally get
+around to merging.  Examples: If distutils was being used exclusively it
+would fix the #! lines in xml/*.  We'd be able to point Python
+$version_of_the_day at setup.py instead of having to sed the Makefile or
+run setup and manually install other files.
+
+Thanks,
+
+James
+  1. http://pullcord.laptop.org:4000/revision/314.1.15/doc/be.1.sgml
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values
new file mode 100644
index 0000000..a4534a2
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values
@@ -0,0 +1,14 @@
+Alt-id: <20090714183404.GB26032@ukfsn.org>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 19:34:04 +0100
+
+
+From: jnrowe@gmail.com
+
+
+In-reply-to: 1f40efc1-6efc-4dd8-bdd2-97907e5aa624
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body
new file mode 100644
index 0000000..24ff7b0
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body
@@ -0,0 +1,58 @@
+"W. Trevor King" <wking@drexel.edu> writes:
+
+> Currently setup.py sets the version number for BE to 0.0.193 and the
+> url to http://panoramicfeedback.com/opensource/. These are both a bit
+> outdated ;).
+
+Right, that should change.
+
+> I've switched my branch over to the current url, and moved to
+> last-commit-timestamp version numbers.
+
+Please, no. Timestamps aren't version strings, that's conflating two
+pieces of information with very different meanings. Correlating the two
+is the job of a changelog.
+
+> This removes the "prefered branch" issues with the old scheme, and
+> version numbers should increase monotonically
+
+The English word “should” is ambiguous in this context. Are you saying
+this is desirable, or are you predicting that it will likely be the
+case?
+
+I don't see how it's either, so am doubly confused :-)
+
+> but it looses any stability information suggested by the preceding
+> 0.0.
+
+The convention for three-part version strings is often:
+
+  * Major release number (big changes in how the program works,
+    increasing monotonically per major release, with “0”indicating no
+    major release yet)
+
+  * Minor release number (smaller impact on how the program works,
+    increasing monotonically per minor release, with “0” indicating no
+    minor release yet since the previous major)
+
+  * Patch release number (bug-fix and other changes that don't affect
+    the documented interface, increasing monotonically per patch
+    release, with “0” indicating no patch release since the previous
+    major or minor)
+
+Obviously there's no standard or enforcement for this, but that's the
+interpretation I usually give to dotted version strings in the absence
+of more formal declaration specific to the project.
+
+> We can add those back in if people want. Does the first 0 mean
+> "interfaces in flux" and the second 0 mean "lots of bugs"? If so, I
+> think we're up to 0.1, since the major features are pretty calm.
+
+I disagree with your interpretation and prefer mine, above; on that
+basis, I agree that we're at least up to version 0.1 by now :-)
+
+-- 
+ \         “A lot of water has been passed under the bridge since this |
+  `\                    variation has been played.” chess book, Russia |
+_o__)                                                                  |
+Ben Finney
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values
new file mode 100644
index 0000000..1b70837
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values
@@ -0,0 +1,14 @@
+Alt-id: <87ocrnjvat.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 22:36:26 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body
new file mode 100644
index 0000000..8b32751
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body
@@ -0,0 +1,14 @@
+Hi,
+
+   > Which we don't bother keeping (also NEWS), since "bzr log" works
+   > so nicely.  If you really want an standard changelog, see
+   > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00186.html
+
+Actually, there's a `bzr log --gnu-changelog` now, and `bzr help
+log-formats` offers some more styles.  (None of them seem to match
+my preferred style for release announcements exactly, which would
+be `git shortlog`-style.)
+
+- Chris.
+-- 
+Chris Ball   <cjb@laptop.org>
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values
new file mode 100644
index 0000000..ea6e6aa
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values
@@ -0,0 +1,14 @@
+Alt-id: <m3ljmrfgot.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 11:05:38 -0400
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+In-reply-to: ea01c122-e629-4d5c-afa7-b180f4a8748b
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body
new file mode 100644
index 0000000..33a8d66
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body
@@ -0,0 +1,51 @@
+I don't think anyone's changing their mind ;), so tallying the
+comments so far:
+
+On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> I still disagree that a timestamp is the right thing to use there. If
+> you want a monotonically-increasing indicator of which revision we're up
+> to, that's immediately available with the revision number from VCS on
+> the main branch. That also has the advantage of producing consecutive
+> numbers for each revision, by definition.
+
++1 for trunk version number.
+
+On Tue, Jul 14, 2009 at 05:27:52PM +0200, Elena of Valhalla wrote:
+> I also have a weak preference for version numbers, as long as they
+> give useful informations on the state the release.
+
++1 for trunk version number.
+
+On Tue, Jul 14, 2009 at 02:29:10PM -0400, Aaron Bentley wrote:
+> We don't do that.  We have official releases every 4 weeks, but we do
+> believe that running bzr.dev is pretty safe, because it's always tested
+> and our test suite is quite thorough.
+
++1 for by hand version bumps.
+
+On Fri, Jul 17, 2009 at 11:37:49PM +0200, Gianluca Montecchi wrote:
+> The version number of trunk _is_ should be the official version number of the 
+> Bugs Everywhere releases. 
+> The version number in branch does not means nothing outside the branch.
+> At least we can have a mechanism to build a version number scheme that is 
+> consistent for us to be able to merge branch easily.
+
++1 for trunk version number.
+
+And me with my timestamps ;).
+
+Sounds like we should go with trunk version number, but that it should
+be set by hand whenever Chris decides to release something, since the
+rest of us don't know what version the trunk is on.  Unless we do
+something like:
+  bzr log -n 0 | grep -B2 'nick: be$' | head -n1 | sed 's/ *revno: \([0-9]*\).*/\1/'
+to extract the last trunk commit referenced from our branch.
+
+Implementation preferences? (i.e. Chris vs. regexp matching :p)
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values
new file mode 100644
index 0000000..1acfd91
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values
@@ -0,0 +1,14 @@
+Alt-id: <20090718105008.GA31639@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 18 Jul 2009 06:50:08 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: c35835c0-8f9f-4090-ba92-1f616867e486
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body
new file mode 100644
index 0000000..063afcb
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body
@@ -0,0 +1,30 @@
+Hi,
+
+   > That's not a changelog, that's a commit log of every source-level
+   > commit made. Far too much detail for a changelog of
+   > *user-visible* changes associated with a release.
+
+I think I agree with both of you. :) It seems like it's both true that
+there's no point in keeping a GNU-style ChangeLog these days, and that
+if we make a release we should write an announce mail that directly
+mentions new user-visible changes as well as attaching the commit log.
+That smaller list of highly user-visible changes could live in NEWS,
+or in the announce mail, or both.
+
+   > I agree that's a problem. I think the solution is to start making
+   > releases, with specific version strings, as source tarballs.
+
+I'm happy to do this if people think it would be useful, and I don't
+yet have a strong opinion on whether the releases should come with
+version numbers or timestamps.
+
+Thanks,
+
+- Chris.
+-- 
+Chris Ball   <cjb@laptop.org>
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values
new file mode 100644
index 0000000..761c219
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values
@@ -0,0 +1,14 @@
+Alt-id: <m3k52bfgf0.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 11:11:31 -0400
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+In-reply-to: ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body
new file mode 100644
index 0000000..1e2a870
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body
@@ -0,0 +1,37 @@
+On Tue, Jul 14, 2009 at 01:17:25PM -0400, W. Trevor King wrote:
+> On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> > "W. Trevor King" <wking@drexel.edu> writes:
+> > 
+> > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > > > Please, no. Timestamps aren't version strings, that's conflating two
+> > > > pieces of information with very different meanings. Correlating the
+> > > > two is the job of a changelog.
+> > > 
+> > > Which we don't bother keeping (also NEWS), since "bzr log" works so
+> > > nicely.
+> > 
+> > That's not a changelog, that's a commit log of every source-level commit
+> > made. Far too much detail for a changelog of *user-visible* changes
+> > associated with a release.
+> 
+> I need a user around to help me determine "user-visable" changes ;).
+> My labmates loose interest after be init/new/comment :p.  None of
+> which has ever changed, other than set-root -> init ;).
+
+Thinking about this some more, I think that the role of the
+main-branch is to officially sanction the current state of the code as
+"released".  If a series of commits will leave a branch in a
+known-unusable form, they should be carried out in some appropriately
+named development branch.  Then the log of commits to the main branch
+("bzr log -n 1" for bzr > ) should produce a fairly respectable
+changelog.  Obviously we are all quite guilty of doing most of our
+development in single branches, but it may be a useful model going
+forward.  This also means that _every_commit_ to a main branch would
+be an official release.
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values
new file mode 100644
index 0000000..4439bad
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values
@@ -0,0 +1,14 @@
+Alt-id: <20090714182034.GA10606@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 14:20:34 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 1f40efc1-6efc-4dd8-bdd2-97907e5aa624
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body
new file mode 100644
index 0000000..e02bd38
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body
@@ -0,0 +1,25 @@
+On Tue, Jul 14, 2009 at 5:11 PM, Chris Ball<cjb@laptop.org> wrote:
+>   > I agree that's a problem. I think the solution is to start making
+>   > releases, with specific version strings, as source tarballs.
+>
+> I'm happy to do this if people think it would be useful, and I don't
+> yet have a strong opinion on whether the releases should come with
+> version numbers or timestamps.
+
+as an user of be that plans to try and "package" it for openembedded,
+a release would be very useful: writing a recipe that downloads a
+specific commit from bzr and builds it is probably feasible, but
+definitely not ideal.
+
+I also have a weak preference for version numbers, as long as they
+give useful informations on the state the release.
+
+-- 
+Elena ``of Valhalla''
+
+email: elena.valhalla@gmail.com
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values
new file mode 100644
index 0000000..5d49c42
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values
@@ -0,0 +1,14 @@
+Alt-id: <5c5e5c350907140827u218553e8rc5773325d43c2bf2@mail.gmail.com>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 17:27:52 +0200
+
+
+From: Elena of Valhalla <elena.valhalla@gmail.com>
+
+
+In-reply-to: aad59898-8949-44fb-ad0b-2acea6eb2ef8
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body
new file mode 100644
index 0000000..d8014d2
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body
@@ -0,0 +1,102 @@
+On Thursday 16 July 2009 12:38:55 W. Trevor King wrote:
+> On Thu, Jul 16, 2009 at 07:32:31PM +1000, Ben Finney wrote:
+> > "W. Trevor King" <wking@drexel.edu> writes:
+> > > On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> > > > "W. Trevor King" <wking@drexel.edu> writes:
+> > > > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > > > > > Please, no. Timestamps aren't version strings, that's conflating
+> > > > > > two pieces of information with very different meanings.
+> > > > > > Correlating the two is the job of a [NEWS file].
+> > > >
+> > > > If you want a monotonically-increasing indicator of which revision
+> > > > we're up to, that's immediately available with the revision number
+> > > > from VCS on the main branch. That also has the advantage of
+> > > > producing consecutive numbers for each revision, by definition.
+> > >
+> > > But not during branch-switches, while my method skips large regions,
+> > > but probably increases during any reasonable branch-switch.
+> >
+> > I've read this several times now, and I don't see what it's saying.
+> >
+> > The assumption I'm making is that there is a single canonical “main
+> > branch”, from which releases will be made.
+>
+> I don't think you need to assume this.  See my "virtual branch"
+> argument below.
+
+But if we have a canonical "main branch" that  we release, and the packager 
+get, we can refer to it as the stable branch, that it is not a bad idea.
+
+
+
+> > The version number set in that branch is the one which determines
+> > the version of Bugs Everywhere as a whole.
+>
+> If you are suggesting that the dev branches adjust their release
+> number _by_hand_ to match the current trunk release number, that
+> allows switching, but sounds like a lot of work and isn't correct
+> anyway, since they are not in the same state as the trunk.
+
+The version number of trunk _is_ should be the official version number of the 
+Bugs Everywhere releases. 
+The version number in branch does not means nothing outside the branch.
+At least we can have a mechanism to build a version number scheme that is 
+consistent for us to be able to merge branch easily.
+
+> > The revision number is only useful in the context of the branch, so it
+> > only matters when comparing versions within a branch. When you switch
+> > between branches, if you're interested in the revision number you'll
+> > still need to know which branch you're talking about.
+>
+> I think this is our main disagreement.  I see all the branches as part
+> of the same codebase, with monotonically increasing timestamp patch
+> numbers.  If you were to collapse all the commit snapshots down into a
+> single chronological "virtual branch", it would still make sense, it
+> would just be a bit unorganized.  We do all try to move in the same
+> general direction ;).
+
+I don't think that, outside the developers, a version number like
+
+cjb@laptop.org-20090713154540-ve4pmydqzb1ghgvc
+
+is a good choice, not for the user of BE, not for the packager of BE
+
+
+> > This, then, is an argument for not having the revision number in the
+> > version string at all. The version then becomes a more traditional
+> > “major.minor.patch” tuple, and is only ever updated when some release
+> > manager of the canonical branch decides it's correct to do so.
+>
+> It is an argument for not using the revision number.  You can avoid
+> revision numbers by using hand-coded patch numbers, or by using
+> timestamps, which is what we're trying to decide on :p.
+
+We can use both.
+During the development we can use version number like
+
+x.y.z.timestamp
+
+As we decide to release a stable version, the release manager set the version 
+number to a more traditional x.y.z format, and create a branch (stable branch)
+
+This way we have these advantages:
+
+1) an user have a simple version number to use for bug report/feature 
+request/help request
+
+2) a packager have an easy life to choose to package a stable or a trunk 
+version, knowing what are they doing
+
+bonus) we can maintain a stable and a developmente source tree/branch, where 
+in the development tree we can make also backward incompatible modification to 
+the source without making any damage to the users/packagers, while in the 
+stable branch we can make only bugfix/security fix or port from the devel branch 
+some interesting features as long as they don't break compatibility.
+
+bye
+Gianluca
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values
new file mode 100644
index 0000000..a828a3a
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values
@@ -0,0 +1,14 @@
+Alt-id: <200907172337.49779.gian@grys.it>
+
+
+Content-type: text/plain
+
+
+Date: Fri, 17 Jul 2009 23:37:49 +0200
+
+
+From: Gianluca Montecchi <gian@grys.it>
+
+
+In-reply-to: f925e56f-26f9-4620-82fb-a0f160f27921
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body
new file mode 100644
index 0000000..4e8445a
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body
@@ -0,0 +1,18 @@
+Currently setup.py sets the version number for BE to 0.0.193 and the
+url to http://panoramicfeedback.com/opensource/.  These are both a bit
+outdated ;).  I've switched my branch over to the current url, and
+moved to last-commit-timestamp version numbers.  This removes the
+"prefered branch" issues with the old scheme, and version numbers
+should increase monotonically, but it looses any stability information
+suggested by the preceding 0.0.
+
+We can add those back in if people want.  Does the first 0 mean
+"interfaces in flux" and the second 0 mean "lots of bugs"?  If so, I
+think we're up to 0.1, since the major features are pretty calm.
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values
new file mode 100644
index 0000000..94bb94d
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values
@@ -0,0 +1,11 @@
+Alt-id: <20090714110543.GB4855@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 07:05:43 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body
new file mode 100644
index 0000000..fce4941
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body
@@ -0,0 +1,72 @@
+On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> "W. Trevor King" <wking@drexel.edu> writes:
+> > I've switched my branch over to the current url, and moved to
+> > last-commit-timestamp version numbers.
+> 
+> Please, no. Timestamps aren't version strings, that's conflating two
+> pieces of information with very different meanings. Correlating the two
+> is the job of a changelog.
+
+Which we don't bother keeping (also NEWS), since "bzr log" works so nicely.
+If you really want an standard changelog, see
+  http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00186.html
+
+> > This removes the "prefered branch" issues with the old scheme, and
+> > version numbers should increase monotonically
+> 
+> The English word “should” is ambiguous in this context. Are you saying
+> this is desirable, or are you predicting that it will likely be the
+> case?
+
+Both.
+
+> I don't see how it's either, so am doubly confused :-)
+
+The timestamp should at least replace the patch release number, which
+you agree is-desirable-to increase motonically ;).  I also predict
+that it will increase monotonically for any given branch, since the
+branch HEAD will have both the most recent commit and the highest
+version number.  The only problem I can think of is having your clock
+_way_ off, and that is unlikely enough to ignore.  If you hop between
+branches, the timestamp is much more likely to increase going to the
+more modern branch than the bzr revision number, which desynchronize
+between branches fairly quickly.
+
+> The convention for three-part version strings is often:
+> 
+>   * Major release number (big changes in how the program works,
+>     increasing monotonically per major release, with “0”indicating no
+>     major release yet)
+> 
+>   * Minor release number (smaller impact on how the program works,
+>     increasing monotonically per minor release, with “0” indicating no
+>     minor release yet since the previous major)
+> 
+>   * Patch release number (bug-fix and other changes that don't affect
+>     the documented interface, increasing monotonically per patch
+>     release, with “0” indicating no patch release since the previous
+>     major or minor)
+
+One problem is that we don't actually have "releases".  People just
+clone a branch, install, and go.  If you're worried about stability,
+just clone from a more stable branch (i.e., Chris' trunk).  I think
+this is good for distributed development, but maybe makes it hard to
+package into a conventional release-based system.  With the bzr patch
+number in setup.py as the patch release number, I would be releasing
+my 0.1.363 while Chris releases his 0.1.314, even though they're at
+about the same point.  I would rather be releasing my
+  0.1.20090714121347
+while Chris releases his
+  0.1.20090713154540
+Since then the similarity is clearer.
+
+At any rate, I think the two approaches are close enough that an
+auto-updating timestamp beats a manually bumped patch number, since
+no-one ever actually bumps the patch number ;).
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values
new file mode 100644
index 0000000..c863757
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values
@@ -0,0 +1,14 @@
+Alt-id: <20090714133732.GB6160@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Tue, 14 Jul 2009 09:37:32 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: 744435b7-1521-4059-a55d-f0c403d7b4d8
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body
new file mode 100644
index 0000000..5eeb353
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body
@@ -0,0 +1,88 @@
+On Thu, Jul 16, 2009 at 07:32:31PM +1000, Ben Finney wrote:
+> "W. Trevor King" <wking@drexel.edu> writes:
+> 
+> > On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> > > "W. Trevor King" <wking@drexel.edu> writes:
+> > > 
+> > > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > > > > Please, no. Timestamps aren't version strings, that's conflating
+> > > > > two pieces of information with very different meanings.
+> > > > > Correlating the two is the job of a [NEWS file].
+> >
+> > > If you want a monotonically-increasing indicator of which revision
+> > > we're up to, that's immediately available with the revision number
+> > > from VCS on the main branch. That also has the advantage of
+> > > producing consecutive numbers for each revision, by definition.
+> > 
+> > But not during branch-switches, while my method skips large regions,
+> > but probably increases during any reasonable branch-switch.
+> 
+> I've read this several times now, and I don't see what it's saying.
+> 
+> The assumption I'm making is that there is a single canonical “main
+> branch”, from which releases will be made.
+
+I don't think you need to assume this.  See my "virtual branch"
+argument below.
+
+> The version number set in that branch is the one which determines
+> the version of Bugs Everywhere as a whole.
+
+If you are suggesting that the dev branches adjust their release
+number _by_hand_ to match the current trunk release number, that
+allows switching, but sounds like a lot of work and isn't correct
+anyway, since they are not in the same state as the trunk.
+
+> The revision number is only useful in the context of the branch, so it
+> only matters when comparing versions within a branch. When you switch
+> between branches, if you're interested in the revision number you'll
+> still need to know which branch you're talking about.
+
+I think this is our main disagreement.  I see all the branches as part
+of the same codebase, with monotonically increasing timestamp patch
+numbers.  If you were to collapse all the commit snapshots down into a
+single chronological "virtual branch", it would still make sense, it
+would just be a bit unorganized.  We do all try to move in the same
+general direction ;).
+
+> Switching between branches doesn't change the canonical version string.
+
+Different released code should have different version numbers.
+
+> > For example, when I upgraded to rich root to pull Ben's patch, I'm not
+> > sure if Chris upgraded the trunk and merged my branch, or just ditched
+> > the trunk and cloned my branch. Using actual bzr revision numbers
+> > would make switching branches that either wrong (in the case of rev-id
+> > decreases) or confusing (in the case of a single non-consecutive
+> > increase).
+> 
+> This, then, is an argument for not having the revision number in the
+> version string at all. The version then becomes a more traditional
+> “major.minor.patch” tuple, and is only ever updated when some release
+> manager of the canonical branch decides it's correct to do so.
+
+It is an argument for not using the revision number.  You can avoid
+revision numbers by using hand-coded patch numbers, or by using
+timestamps, which is what we're trying to decide on :p.
+
+> If we use the ‘bzr version-info --format=python > foo_version.py’
+> command in some build routine, the branch's revision number will be
+> available directly within Python by importing that module. That would
+> allow it to be output in some UI, if that's what you're interested in
+> seeing.
+
+True.  Which means that whichever version string wins out, the other
+side will still be able to access the info we both want included ;).
+We can certainly suggest that bug reporters submit their
+  be --verbose-version
+when they submit bugs.  The only role of the official "version string"
+is to make life easy for packagers.  If they woln't be switching
+branches, then either of our proposals are fine.  If they will, then
+I think timestamps work better.
+
+-- 
+This email may be signed or encrypted with GPG (http://www.gnupg.org).
+The GPG signature (if present) will be attached as 'signature.asc'.
+For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
+
+My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values
new file mode 100644
index 0000000..36f4007
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values
@@ -0,0 +1,14 @@
+Alt-id: <20090716103855.GA8579@mjolnir.home.net>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 16 Jul 2009 06:38:55 -0400
+
+
+From: '"W. Trevor King" <wking@drexel.edu>'
+
+
+In-reply-to: fdb615a4-168a-467b-8090-875c998455e5
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body
new file mode 100644
index 0000000..b36292a
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body
@@ -0,0 +1,55 @@
+"W. Trevor King" <wking@drexel.edu> writes:
+
+> On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
+> > "W. Trevor King" <wking@drexel.edu> writes:
+> > 
+> > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > > > Please, no. Timestamps aren't version strings, that's conflating
+> > > > two pieces of information with very different meanings.
+> > > > Correlating the two is the job of a [NEWS file].
+>
+> > If you want a monotonically-increasing indicator of which revision
+> > we're up to, that's immediately available with the revision number
+> > from VCS on the main branch. That also has the advantage of
+> > producing consecutive numbers for each revision, by definition.
+> 
+> But not during branch-switches, while my method skips large regions,
+> but probably increases during any reasonable branch-switch.
+
+I've read this several times now, and I don't see what it's saying.
+
+The assumption I'm making is that there is a single canonical “main
+branch”, from which releases will be made. The version number set in
+that branch is the one which determines the version of Bugs Everywhere
+as a whole.
+
+The revision number is only useful in the context of the branch, so it
+only matters when comparing versions within a branch. When you switch
+between branches, if you're interested in the revision number you'll
+still need to know which branch you're talking about.
+
+Switching between branches doesn't change the canonical version string.
+
+> For example, when I upgraded to rich root to pull Ben's patch, I'm not
+> sure if Chris upgraded the trunk and merged my branch, or just ditched
+> the trunk and cloned my branch. Using actual bzr revision numbers
+> would make switching branches that either wrong (in the case of rev-id
+> decreases) or confusing (in the case of a single non-consecutive
+> increase).
+
+This, then, is an argument for not having the revision number in the
+version string at all. The version then becomes a more traditional
+“major.minor.patch” tuple, and is only ever updated when some release
+manager of the canonical branch decides it's correct to do so.
+
+If we use the ‘bzr version-info --format=python > foo_version.py’
+command in some build routine, the branch's revision number will be
+available directly within Python by importing that module. That would
+allow it to be output in some UI, if that's what you're interested in
+seeing.
+
+-- 
+ \     “Never do anything against conscience even if the state demands |
+  `\                                             it.” —Albert Einstein |
+_o__)                                                                  |
+Ben Finney
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values
new file mode 100644
index 0000000..d373a73
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values
@@ -0,0 +1,14 @@
+Alt-id: <87d481ht1s.fsf@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Thu, 16 Jul 2009 19:32:31 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body
new file mode 100644
index 0000000..30e3cbd
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body
@@ -0,0 +1,44 @@
+"W. Trevor King" <wking@drexel.edu> writes:
+
+> On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
+> > Please, no. Timestamps aren't version strings, that's conflating two
+> > pieces of information with very different meanings. Correlating the
+> > two is the job of a changelog.
+> 
+> Which we don't bother keeping (also NEWS), since "bzr log" works so
+> nicely.
+
+That's not a changelog, that's a commit log of every source-level commit
+made. Far too much detail for a changelog of *user-visible* changes
+associated with a release.
+
+> The timestamp should at least replace the patch release number, which
+> you agree is-desirable-to increase motonically ;).
+
+I still disagree that a timestamp is the right thing to use there. If
+you want a monotonically-increasing indicator of which revision we're up
+to, that's immediately available with the revision number from VCS on
+the main branch. That also has the advantage of producing consecutive
+numbers for each revision, by definition.
+
+> One problem is that we don't actually have "releases". People just
+> clone a branch, install, and go.
+
+I agree that's a problem. I think the solution is to start making
+releases, with specific version strings, as source tarballs.
+
+James Rowe <jnrowe@gmail.com> writes:
+
+>   Isn't there a bzr web interface that at least supports creating
+> tarballs/zips?
+
+Even better: ‘bzr export /tmp/foo.tar.gz’ will create a source tarball
+of all the files in the branch's VCS inventory. All we need to do is
+start the practice of tagging a release in the VCS, and export the
+tarball at that time.
+
+-- 
+ \       “Pinky, are you pondering what I'm pondering?” “Well, I think |
+  `\   so (hiccup), but Kevin Costner with an English accent?” —_Pinky |
+_o__)                                                   and The Brain_ |
+Ben Finney
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values
new file mode 100644
index 0000000..aa9b55f
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values
@@ -0,0 +1,14 @@
+Alt-id: <87k52bjoxe.fsf_-_@benfinney.id.au>
+
+
+Content-type: text/plain
+
+
+Date: Wed, 15 Jul 2009 00:54:05 +1000
+
+
+From: Ben Finney <bignose+hates-spam@benfinney.id.au>
+
+
+In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c
+
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/values
new file mode 100644
index 0000000..b9e8dff
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/values
@@ -0,0 +1,17 @@
+creator: W. Trevor King <wking@drexel.edu>
+
+
+reporter: W. Trevor King <wking@drexel.edu>
+
+
+severity: wishlist
+
+
+status: open
+
+
+summary: How should we version BE?
+
+
+time: Tue, 21 Jul 2009 17:19:22 +0000
+