From 9ef8e376212786d8a99cfa19bfcd9c6e70735d0a Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Tue, 21 Jul 2009 15:22:09 -0400 Subject: I imported a few threads from the mailing list as wishlist bugs. 12c:uw: Bug aggregation. Multi-repo meta-BE? 529:ow: How should we version BE? 2f0:aw: Static html report generation 22b:aw: Sorting targets chronologically d99:aw: CherryPy interface "Cherry-flavored BE" e08:aw: Interactive email interface --- .../0c40c13a-3515-4b45-a8c3-142cceab9254/body | 36 +++++++ .../0c40c13a-3515-4b45-a8c3-142cceab9254/values | 14 +++ .../1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body | 115 +++++++++++++++++++++ .../1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values | 14 +++ .../2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body | 58 +++++++++++ .../2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values | 14 +++ .../2c95ee07-462d-42cf-8dc3-8f5389a392cb/body | 96 +++++++++++++++++ .../2c95ee07-462d-42cf-8dc3-8f5389a392cb/values | 14 +++ .../31beb504-c72b-4304-95ba-a66d2bcbc46a/body | 52 ++++++++++ .../31beb504-c72b-4304-95ba-a66d2bcbc46a/values | 14 +++ .../6e315abe-a080-4369-8729-4aea2dee8494/body | 38 +++++++ .../6e315abe-a080-4369-8729-4aea2dee8494/values | 14 +++ .../744435b7-1521-4059-a55d-f0c403d7b4d8/body | 58 +++++++++++ .../744435b7-1521-4059-a55d-f0c403d7b4d8/values | 14 +++ .../a536cee5-cc8d-4b18-b491-657e0c7998b4/body | 14 +++ .../a536cee5-cc8d-4b18-b491-657e0c7998b4/values | 14 +++ .../a845096e-3cdf-41ed-a0e3-283439665b92/body | 51 +++++++++ .../a845096e-3cdf-41ed-a0e3-283439665b92/values | 14 +++ .../aad59898-8949-44fb-ad0b-2acea6eb2ef8/body | 30 ++++++ .../aad59898-8949-44fb-ad0b-2acea6eb2ef8/values | 14 +++ .../ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body | 37 +++++++ .../ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values | 14 +++ .../b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body | 25 +++++ .../b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values | 14 +++ .../c35835c0-8f9f-4090-ba92-1f616867e486/body | 102 ++++++++++++++++++ .../c35835c0-8f9f-4090-ba92-1f616867e486/values | 14 +++ .../cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body | 18 ++++ .../cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values | 11 ++ .../ea01c122-e629-4d5c-afa7-b180f4a8748b/body | 72 +++++++++++++ .../ea01c122-e629-4d5c-afa7-b180f4a8748b/values | 14 +++ .../f925e56f-26f9-4620-82fb-a0f160f27921/body | 88 ++++++++++++++++ .../f925e56f-26f9-4620-82fb-a0f160f27921/values | 14 +++ .../fdb615a4-168a-467b-8090-875c998455e5/body | 55 ++++++++++ .../fdb615a4-168a-467b-8090-875c998455e5/values | 14 +++ .../ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body | 44 ++++++++ .../ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values | 14 +++ 36 files changed, 1238 insertions(+) create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body create mode 100644 .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values (limited to '.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments') 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 + + +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" 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" ' + + +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 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 + + +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 + + +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" ' + + +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" 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 + + +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 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: + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 11:05:38 -0400 + + +From: Chris Ball + + +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" ' + + +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 + +_______________________________________________ +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: + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 11:11:31 -0400 + + +From: Chris Ball + + +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" 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" ' + + +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 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 + + +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" writes: +> > > On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote: +> > > > "W. Trevor King" 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 + + +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" ' + 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" 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" ' + + +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" writes: +> +> > On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote: +> > > "W. Trevor King" 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" ' + + +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" writes: + +> On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote: +> > "W. Trevor King" 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 + + +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" 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 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 + + +In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c + -- cgit From 830522c293a479636d7bfc0fff125ec57f06e9a3 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Mon, 31 Aug 2009 12:32:05 -0400 Subject: Added libbe/upgrade.py to handle upgrading on-disk bugdirs. --- .../comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values | 6 +++--- .../comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values | 6 +++--- .../comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values | 6 +++--- .../comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values | 6 +++--- .../comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values | 6 +++--- .../comments/6e315abe-a080-4369-8729-4aea2dee8494/values | 6 +++--- .../comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values | 6 +++--- .../comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values | 6 +++--- .../comments/a845096e-3cdf-41ed-a0e3-283439665b92/values | 6 +++--- .../comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values | 6 +++--- .../comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values | 6 +++--- .../comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values | 6 +++--- .../comments/c35835c0-8f9f-4090-ba92-1f616867e486/values | 6 +++--- .../comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values | 6 +++--- .../comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values | 6 +++--- .../comments/f925e56f-26f9-4620-82fb-a0f160f27921/values | 6 +++--- .../comments/fdb615a4-168a-467b-8090-875c998455e5/values | 6 +++--- .../comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values | 6 +++--- 18 files changed, 54 insertions(+), 54 deletions(-) (limited to '.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments') 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 index c064938..e7077e7 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <20090714142942.GA5717@ukfsn.org> -Content-type: text/plain +Author: James Rowe -Date: Tue, 14 Jul 2009 15:29:42 +0100 +Content-type: text/plain -From: James Rowe +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/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values index 4538a9f..ce34e73 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <20090714171725.GB10445@mjolnir.home.net> -Content-type: text/plain +Author: '"W. Trevor King" ' -Date: Tue, 14 Jul 2009 13:17:25 -0400 +Content-type: text/plain -From: '"W. Trevor King" ' +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values index 4e3ade1..320c484 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <87hbxdhtkp.fsf@benfinney.id.au> -Content-type: text/plain +Author: Ben Finney -Date: Thu, 16 Jul 2009 19:21:10 +1000 +Content-type: text/plain -From: Ben Finney +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values index 5134cf2..8cfe1b0 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <4A5CCE76.9040106@aaronbentley.com> -Content-type: text/plain +Author: Aaron Bentley -Date: Tue, 14 Jul 2009 14:29:10 -0400 +Content-type: text/plain -From: Aaron Bentley +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values index 0c1e529..df4c701 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <20090714191145.GB10606@mjolnir.home.net> -Content-type: text/plain +Author: '"W. Trevor King" ' -Date: Tue, 14 Jul 2009 15:11:45 -0400 +Content-type: text/plain -From: '"W. Trevor King" ' +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/6e315abe-a080-4369-8729-4aea2dee8494/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values index a4534a2..4f1d60d 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <20090714183404.GB26032@ukfsn.org> -Content-type: text/plain +Author: jnrowe@gmail.com -Date: Tue, 14 Jul 2009 19:34:04 +0100 +Content-type: text/plain -From: jnrowe@gmail.com +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/744435b7-1521-4059-a55d-f0c403d7b4d8/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values index 1b70837..c5d9cbb 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <87ocrnjvat.fsf@benfinney.id.au> -Content-type: text/plain +Author: Ben Finney -Date: Tue, 14 Jul 2009 22:36:26 +1000 +Content-type: text/plain -From: Ben Finney +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/a536cee5-cc8d-4b18-b491-657e0c7998b4/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values index ea6e6aa..239feb5 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: -Content-type: text/plain +Author: Chris Ball -Date: Tue, 14 Jul 2009 11:05:38 -0400 +Content-type: text/plain -From: Chris Ball +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values index 1acfd91..ee9cc4b 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <20090718105008.GA31639@mjolnir.home.net> -Content-type: text/plain +Author: '"W. Trevor King" ' -Date: Sat, 18 Jul 2009 06:50:08 -0400 +Content-type: text/plain -From: '"W. Trevor King" ' +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values index 761c219..466be33 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: -Content-type: text/plain +Author: Chris Ball -Date: Tue, 14 Jul 2009 11:11:31 -0400 +Content-type: text/plain -From: Chris Ball +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values index 4439bad..fca4962 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <20090714182034.GA10606@mjolnir.home.net> -Content-type: text/plain +Author: '"W. Trevor King" ' -Date: Tue, 14 Jul 2009 14:20:34 -0400 +Content-type: text/plain -From: '"W. Trevor King" ' +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values index 5d49c42..57b408f 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <5c5e5c350907140827u218553e8rc5773325d43c2bf2@mail.gmail.com> -Content-type: text/plain +Author: Elena of Valhalla -Date: Tue, 14 Jul 2009 17:27:52 +0200 +Content-type: text/plain -From: Elena of Valhalla +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values index a828a3a..c7c0273 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <200907172337.49779.gian@grys.it> -Content-type: text/plain +Author: Gianluca Montecchi -Date: Fri, 17 Jul 2009 23:37:49 +0200 +Content-type: text/plain -From: Gianluca Montecchi +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values index 94bb94d..2df38ed 100644 --- 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 @@ -1,11 +1,11 @@ Alt-id: <20090714110543.GB4855@mjolnir.home.net> -Content-type: text/plain +Author: '"W. Trevor King" ' -Date: Tue, 14 Jul 2009 07:05:43 -0400 +Content-type: text/plain -From: '"W. Trevor King" ' +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values index c863757..42e7df8 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <20090714133732.GB6160@mjolnir.home.net> -Content-type: text/plain +Author: '"W. Trevor King" ' -Date: Tue, 14 Jul 2009 09:37:32 -0400 +Content-type: text/plain -From: '"W. Trevor King" ' +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values index 36f4007..4e46802 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <20090716103855.GA8579@mjolnir.home.net> -Content-type: text/plain +Author: '"W. Trevor King" ' -Date: Thu, 16 Jul 2009 06:38:55 -0400 +Content-type: text/plain -From: '"W. Trevor King" ' +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/fdb615a4-168a-467b-8090-875c998455e5/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values index d373a73..3a42917 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <87d481ht1s.fsf@benfinney.id.au> -Content-type: text/plain +Author: Ben Finney -Date: Thu, 16 Jul 2009 19:32:31 +1000 +Content-type: text/plain -From: Ben Finney +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/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values index aa9b55f..56bef0b 100644 --- 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 @@ -1,13 +1,13 @@ Alt-id: <87k52bjoxe.fsf_-_@benfinney.id.au> -Content-type: text/plain +Author: Ben Finney -Date: Wed, 15 Jul 2009 00:54:05 +1000 +Content-type: text/plain -From: Ben Finney +Date: Wed, 15 Jul 2009 00:54:05 +1000 In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c -- cgit