aboutsummaryrefslogtreecommitdiffstats
path: root/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments
diff options
context:
space:
mode:
authorW. Trevor King <wking@drexel.edu>2009-12-13 06:19:23 -0500
committerW. Trevor King <wking@drexel.edu>2009-12-13 06:19:23 -0500
commit4d057dab603f42ec40b911dbee6792dcf107bd14 (patch)
tree9a73459aa160e3c96f4893b132543f412ca6e97f /.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments
parentdff6bd9bf89ca80e2265696a478e540476718c9c (diff)
downloadbugseverywhere-4d057dab603f42ec40b911dbee6792dcf107bd14.tar.gz
Converted libbe.storage.vcs.base to new Storage format.
Diffstat (limited to '.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments')
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body36
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/body27
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/values11
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body115
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body58
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body96
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body52
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/body51
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body38
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/body22
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body58
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/body36
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/body102
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body51
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body30
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body37
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body25
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body102
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body18
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values11
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body72
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body88
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/body2
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/values8
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body55
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values14
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body44
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values14
48 files changed, 0 insertions, 1553 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
deleted file mode 100644
index fa9e963..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body
+++ /dev/null
@@ -1,36 +0,0 @@
-* 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
deleted file mode 100644
index e7077e7..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <20090714142942.GA5717@ukfsn.org>
-
-
-Author: James Rowe <jnrowe@gmail.com>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 15:29:42 +0100
-
-
-In-reply-to: ea01c122-e629-4d5c-afa7-b180f4a8748b
-
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/body
deleted file mode 100644
index 8c890f3..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/body
+++ /dev/null
@@ -1,27 +0,0 @@
-"W. Trevor King" <wking@drexel.edu> writes:
-
-> On Tue, Nov 17, 2009 at 01:41:26PM -0300, Nicolas Alvarez wrote:
-> > I'm using the latest version available on Debian
-> > (0.0.193+bzr.r217-2). I should ask for an updated package...
->
-[…]
-
-> There is also an outstanding Debian bug for updating the Debian package
-> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544515
-> so there may be a more current package on the way, but I don't know
-> about timeframes for that sort of thing.
-
-It would make it much easier on the Debian package maintainer if the
-Bugs Everywhere project would make conventional tarball releases, with
-conventional version numbers, with a changelog describing what has
-changed between versions.
-
-Trying to maintain a package of a project that is only made available by
-undifferentiated VCS revision numbers is a lot more effort, and so
-doesn't happen very often.
-
---
- \ “Roll dice!” “Why?” “Shut up! I don't need your fucking |
- `\ *input*, I need you to roll dice!” —Luke Crane, demonstrating |
-_o__) his refined approach to play testing, 2009 |
-Ben Finney
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/values
deleted file mode 100644
index 3b45fbf..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1847f1f8-525a-42c4-ae2b-e9377459d2a6/values
+++ /dev/null
@@ -1,11 +0,0 @@
-Alt-id: <87d43gn8ju.fsf_-_@benfinney.id.au>
-
-
-Author: Ben Finney <bignose+hates-spam@benfinney.id.au>
-
-
-Content-type: text/plain
-
-
-Date: Wed, 18 Nov 2009 13:30:29 +0000
-
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
deleted file mode 100644
index 7e1434b..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body
+++ /dev/null
@@ -1,115 +0,0 @@
-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
deleted file mode 100644
index 9e84a24..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <20090714171725.GB10445@mjolnir.home.net>
-
-
-Author: W. Trevor King <wking@drexel.edu>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 13:17:25 -0400
-
-
-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
deleted file mode 100644
index a0b6a14..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body
+++ /dev/null
@@ -1,58 +0,0 @@
-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
deleted file mode 100644
index 320c484..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <87hbxdhtkp.fsf@benfinney.id.au>
-
-
-Author: Ben Finney <bignose+hates-spam@benfinney.id.au>
-
-
-Content-type: text/plain
-
-
-Date: Thu, 16 Jul 2009 19:21:10 +1000
-
-
-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
deleted file mode 100644
index 5f478b5..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body
+++ /dev/null
@@ -1,96 +0,0 @@
------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
deleted file mode 100644
index 8cfe1b0..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <4A5CCE76.9040106@aaronbentley.com>
-
-
-Author: Aaron Bentley <aaron@aaronbentley.com>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 14:29:10 -0400
-
-
-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
deleted file mode 100644
index b34e037..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body
+++ /dev/null
@@ -1,52 +0,0 @@
-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
deleted file mode 100644
index e0c0955..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <20090714191145.GB10606@mjolnir.home.net>
-
-
-Author: W. Trevor King <wking@drexel.edu>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 15:11:45 -0400
-
-
-In-reply-to: 6e315abe-a080-4369-8729-4aea2dee8494
-
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/body
deleted file mode 100644
index 4ebb4f2..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/body
+++ /dev/null
@@ -1,51 +0,0 @@
-"W. Trevor King" <wking@drexel.edu> writes:
-
-> ** NEWS file
-
-Speaking as the package maintainer, I would like a ‘ChangeLog’ file
-separate from a ‘NEWS’ file.
-
-The ‘NEWS’ file would continue to be hand-edited, and would be a
-high-level view of user-visible changes in the project each version.
-Users could reasonably expect to be interested in this file when
-installing a new version. It would also make sense to retire old news
-From this file once it becomes sufficiently old, to keep it relevant to
-users to read.
-
-
-The ‘ChangeLog’ would be an automatically-generated changelog of
-low-level changes, not for general human consumption but for letting
-recipients have a fighting chance at knowing the historical context of a
-particular change without access to the VCS. It would probably be best
-done as Trevor says:
-
-> Depending on our level of masochism, either something starting out
-> along the lines of [2]
-> bzr log --gnu-changelog -n1 -r 200..
-
-That makes it necessary to add the changelog file to the tarball, since
-it won't be a file tracked by VCS and therefore won't be exported. Not a
-problem::
-
- $ release_version="1.0.0"
- $ release_name="be-$release_version"
- $ tarball_file=../$release_name.tar.gz
- $ work_dir=$(mktemp -t -d)
- $ export_dir=$work_dir/$release_name
- $ changelog_file=$export_dir/ChangeLog
-
- $ bzr export $export_dir
- $ bzr log --gnu-changelog -n1 -r ..tag:"$release_version" > $changelog_file
- $ tar -czf $tarball_file $export_dir
- $ rm -r $work_dir/
-
- $ ls $tarball_file
- ../be-1.0.0.tar.gz
- $ tar -tzf $tarball_file | grep ChangeLog
- be-1.0.0/ChangeLog
-
---
- \ “I bought a dog the other day. I named him Stay. It's fun to |
- `\ call him. ‘Come here, Stay! Come here, Stay!’ He went insane. |
-_o__) Now he just ignores me and keeps typing.” —Steven Wright |
-Ben Finney
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/values
deleted file mode 100644
index b45a747..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/49e0425b-3332-4d0e-b371-300eccd55370/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <873a4cmjw5.fsf@benfinney.id.au>
-
-
-Author: Ben Finney <bignose+hates-spam@benfinney.id.au>
-
-
-Content-type: text/plain
-
-
-Date: Wed, 18 Nov 2009 22:23:06 +0000
-
-
-In-reply-to: a4720227-43cf-49aa-8f9f-f49f46e3e809
-
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
deleted file mode 100644
index 7ffe231..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body
+++ /dev/null
@@ -1,38 +0,0 @@
-[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
deleted file mode 100644
index 4f1d60d..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <20090714183404.GB26032@ukfsn.org>
-
-
-Author: jnrowe@gmail.com
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 19:34:04 +0100
-
-
-In-reply-to: 1f40efc1-6efc-4dd8-bdd2-97907e5aa624
-
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/body
deleted file mode 100644
index d00eb64..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/body
+++ /dev/null
@@ -1,22 +0,0 @@
-Hi,
-
- > It would make it much easier on the Debian package maintainer if
- > the Bugs Everywhere project would make conventional tarball
- > releases, with conventional version numbers, with a changelog
- > describing what has changed between versions.
-
-Fair point.
-
-How do people feel about pushing for a 1.0 release, with Trevor's tree
-plus a finished cfbe merge? Or would we rather wait until afterwards
-to try for cfbe?
-
-- Chris.
---
-Chris Ball <cjb@laptop.org>
-One Laptop Per Child
-
-_______________________________________________
-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/72a519e3-3d6b-4f0f-b412-1310efd255eb/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/values
deleted file mode 100644
index 4fb068d..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/72a519e3-3d6b-4f0f-b412-1310efd255eb/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <m3ocn09310.fsf@pullcord.laptop.org>
-
-
-Author: Chris Ball <cjb@laptop.org>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 17 Nov 2009 22:53:31 +0000
-
-
-In-reply-to: 1847f1f8-525a-42c4-ae2b-e9377459d2a6
-
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
deleted file mode 100644
index 24ff7b0..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body
+++ /dev/null
@@ -1,58 +0,0 @@
-"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
deleted file mode 100644
index c5d9cbb..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <87ocrnjvat.fsf@benfinney.id.au>
-
-
-Author: Ben Finney <bignose+hates-spam@benfinney.id.au>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 22:36:26 +1000
-
-
-In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c
-
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/body
deleted file mode 100644
index a3fc57f..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/body
+++ /dev/null
@@ -1,36 +0,0 @@
-I've written up a little release script that bundles all the steps
-we've mentioned so far into a single command. Of course, we'll still
-have to keep NEWS up to date on our own.
-
-The output prints a trace of what's going on:
-
- $ ./release.py 1.0.0
- set libbe.version._VERSION = '1.0.0'
- updating AUTHORS
- updating ./becommands/assign.py
- updating ./becommands/html.py
- ...
- commit current status: Bumped to version 1.0.0
- tag current revision 1.0.0
- export current revision to be-1.0.0
- generate libbe/_version.py
- copy libbe/_version.py to be-1.0.0/libbe/_version.py
- generate ChangeLog file be-1.0.0/ChangeLog up to tag 1.0.0
- set vcs_name in be-1.0.0/.be/settings to None
- create tarball be-1.0.0.tar.gz
- remove be-1.0.0
-
-Since we'll be distributing a non-bzr-repo version, it would be nice
-to adapt our 'submit bug' procedure (outlined on the main page) to one
-that works with this setup. Without guaranteed versioning, that would
-probably be something along the lines of
- be email-bugs [--to be-devel@bugseverywhere.org] BUG-ID ...
-With interfaces/email/interactive listening on the recieving end to
-grab new-bug emails and import them into an incoming bug repository.
-
---
-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/96abea83-9867-4c21-8eb8-9e1b1093cba4/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/values
deleted file mode 100644
index b6d25cb..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/96abea83-9867-4c21-8eb8-9e1b1093cba4/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <20091120132219.GA17577@mjolnir.home.net>
-
-
-Author: W. Trevor King <wking@drexel.edu>
-
-
-Content-type: text/plain
-
-
-Date: Fri, 20 Nov 2009 13:22:19 +0000
-
-
-In-reply-to: 49e0425b-3332-4d0e-b371-300eccd55370
-
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/body
deleted file mode 100644
index 5d29f85..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/body
+++ /dev/null
@@ -1,102 +0,0 @@
-On Tue, Nov 17, 2009 at 05:53:31PM -0500, Chris Ball wrote:
-> > It would make it much easier on the Debian package maintainer if
-> > the Bugs Everywhere project would make conventional tarball
-> > releases, with conventional version numbers, with a changelog
-> > describing what has changed between versions.
-> How do people feel about pushing for a 1.0 release, with Trevor's tree
-> plus a finished cfbe merge? Or would we rather wait until afterwards
-> to try for cfbe?
-
-Sounds good to me. Not that my tree is much ahead of the trunk at the
-moment. We've talked over most of these issues a few times, so I'll
-just summarize where I think we stand on the steps needed to make a
-release.
-
-** cfbe integration
-
-Postpone until we work out bzr/hg versioning [1]?
-
-** Conventional version number
-
-Set to "1.0.0" using libbe.version._VERSION.
-
-** NEWS file
-
-Depending on our level of masochism, either something starting out
-along the lines of [2]
- bzr log --gnu-changelog -n1 -r 200..
-(commit 200, or
- aaron.bentley@utoronto.ca-20060411035623-9b8d222282a26ce1
- was the last time anyone touched the NEWS file),
-or a much abbreviated entry [3,4], along the lines of my current NEWS
-file (changed just a few minutes ago).
-
-** Tag bzr commit
-
- bzr tag 1.0.0
-
-** Create tarball
-
-From Ben[5]:
- bzr export /tmp/be-1.0.0.tar.gz
-
-
-References:
-
-[1]
-On Thu, Jul 23, 2009 at 05:38:03PM -0400, Steve Losh wrote:
-> On Jul 21, 2009, at 9:59 AM, W. Trevor King wrote:
-> > Steve's also versioning it with Mercurial. Will he mind changing to
-> > Bazaar?
->
-> Yeah, I've tried bazaar but really don't like the interface at all. If
-> everyone else really wants me to move it over I guess I can though.
-
-[2]
-On Tue, Jul 14, 2009 at 11:05:38AM -0400, Chris Ball wrote:
-> 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.)
-
-[3]
-On Thu, Jul 16, 2009 at 07:21:10PM +1000, Ben Finney wrote:
-> 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.
-
-[4]
-On Tue, Jul 14, 2009 at 11:11:31AM -0400, Chris Ball wrote:
-> 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.
-
-[5]
-On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
-> 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.
-
---
-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/a4720227-43cf-49aa-8f9f-f49f46e3e809/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/values
deleted file mode 100644
index 7f205d6..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a4720227-43cf-49aa-8f9f-f49f46e3e809/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <20091118011403.GB9503@mjolnir.home.net>
-
-
-Author: W. Trevor King <wking@drexel.edu>
-
-
-Content-type: text/plain
-
-
-Date: Wed, 18 Nov 2009 01:14:03 +0000
-
-
-In-reply-to: 72a519e3-3d6b-4f0f-b412-1310efd255eb
-
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
deleted file mode 100644
index 8b32751..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body
+++ /dev/null
@@ -1,14 +0,0 @@
-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
deleted file mode 100644
index 239feb5..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <m3ljmrfgot.fsf@pullcord.laptop.org>
-
-
-Author: Chris Ball <cjb@laptop.org>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 11:05:38 -0400
-
-
-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
deleted file mode 100644
index 33a8d66..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body
+++ /dev/null
@@ -1,51 +0,0 @@
-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
deleted file mode 100644
index b757933..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <20090718105008.GA31639@mjolnir.home.net>
-
-
-Author: W. Trevor King <wking@drexel.edu>
-
-
-Content-type: text/plain
-
-
-Date: Sat, 18 Jul 2009 06:50:08 -0400
-
-
-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
deleted file mode 100644
index 063afcb..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body
+++ /dev/null
@@ -1,30 +0,0 @@
-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
deleted file mode 100644
index 466be33..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <m3k52bfgf0.fsf@pullcord.laptop.org>
-
-
-Author: Chris Ball <cjb@laptop.org>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 11:11:31 -0400
-
-
-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
deleted file mode 100644
index 1e2a870..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body
+++ /dev/null
@@ -1,37 +0,0 @@
-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
deleted file mode 100644
index b5c41c9..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <20090714182034.GA10606@mjolnir.home.net>
-
-
-Author: W. Trevor King <wking@drexel.edu>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 14:20:34 -0400
-
-
-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
deleted file mode 100644
index e02bd38..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body
+++ /dev/null
@@ -1,25 +0,0 @@
-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
deleted file mode 100644
index 57b408f..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <5c5e5c350907140827u218553e8rc5773325d43c2bf2@mail.gmail.com>
-
-
-Author: Elena of Valhalla <elena.valhalla@gmail.com>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 17:27:52 +0200
-
-
-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
deleted file mode 100644
index d8014d2..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body
+++ /dev/null
@@ -1,102 +0,0 @@
-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
deleted file mode 100644
index c7c0273..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <200907172337.49779.gian@grys.it>
-
-
-Author: Gianluca Montecchi <gian@grys.it>
-
-
-Content-type: text/plain
-
-
-Date: Fri, 17 Jul 2009 23:37:49 +0200
-
-
-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
deleted file mode 100644
index 4e8445a..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body
+++ /dev/null
@@ -1,18 +0,0 @@
-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
deleted file mode 100644
index 00309a2..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values
+++ /dev/null
@@ -1,11 +0,0 @@
-Alt-id: <20090714110543.GB4855@mjolnir.home.net>
-
-
-Author: W. Trevor King <wking@drexel.edu>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 07:05:43 -0400
-
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
deleted file mode 100644
index fce4941..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body
+++ /dev/null
@@ -1,72 +0,0 @@
-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
deleted file mode 100644
index a3f74c4..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <20090714133732.GB6160@mjolnir.home.net>
-
-
-Author: W. Trevor King <wking@drexel.edu>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 09:37:32 -0400
-
-
-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
deleted file mode 100644
index 5eeb353..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body
+++ /dev/null
@@ -1,88 +0,0 @@
-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
deleted file mode 100644
index 63a2cae..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <20090716103855.GA8579@mjolnir.home.net>
-
-
-Author: W. Trevor King <wking@drexel.edu>
-
-
-Content-type: text/plain
-
-
-Date: Thu, 16 Jul 2009 06:38:55 -0400
-
-
-In-reply-to: fdb615a4-168a-467b-8090-875c998455e5
-
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/body
deleted file mode 100644
index dee72c7..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/body
+++ /dev/null
@@ -1,2 +0,0 @@
-Verdict: run releases.py periodically, and post the tarballs on the
-web.
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/values
deleted file mode 100644
index 2e85e56..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f92c6180-0ed8-4acc-8ced-22995a0c016b/values
+++ /dev/null
@@ -1,8 +0,0 @@
-Author: W. Trevor King <wking@drexel.edu>
-
-
-Content-type: text/plain
-
-
-Date: Fri, 20 Nov 2009 21:45:50 +0000
-
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
deleted file mode 100644
index b36292a..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body
+++ /dev/null
@@ -1,55 +0,0 @@
-"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
deleted file mode 100644
index 3a42917..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <87d481ht1s.fsf@benfinney.id.au>
-
-
-Author: Ben Finney <bignose+hates-spam@benfinney.id.au>
-
-
-Content-type: text/plain
-
-
-Date: Thu, 16 Jul 2009 19:32:31 +1000
-
-
-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
deleted file mode 100644
index 30e3cbd..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body
+++ /dev/null
@@ -1,44 +0,0 @@
-"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
deleted file mode 100644
index 56bef0b..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <87k52bjoxe.fsf_-_@benfinney.id.au>
-
-
-Author: Ben Finney <bignose+hates-spam@benfinney.id.au>
-
-
-Content-type: text/plain
-
-
-Date: Wed, 15 Jul 2009 00:54:05 +1000
-
-
-In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c
-