diff options
| author | Chris Ball <cjb@laptop.org> | 2009-07-23 17:49:13 -0400 |
|---|---|---|
| committer | Chris Ball <cjb@laptop.org> | 2009-07-23 17:49:13 -0400 |
| commit | 6a639574fa95e50f82fa3052e5524b961295a7ab (patch) | |
| tree | b498654ed1dcbdbba94605292c280c883c5e9faa /.be/bugs | |
| parent | 5e249abfee7273c79640c4211607a6b4bf7b374c (diff) | |
| parent | caf0111d9c571ac268c235880e6d18fa512e9efa (diff) | |
| download | bugseverywhere-6a639574fa95e50f82fa3052e5524b961295a7ab.tar.gz | |
Merge large rework from W. Trevor King.
Diffstat (limited to '.be/bugs')
145 files changed, 4181 insertions, 1 deletions
diff --git a/.be/bugs/00f26f04-9202-4288-8744-b29abc2342d6/values b/.be/bugs/00f26f04-9202-4288-8744-b29abc2342d6/values index 420d967..2094f46 100644 --- a/.be/bugs/00f26f04-9202-4288-8744-b29abc2342d6/values +++ b/.be/bugs/00f26f04-9202-4288-8744-b29abc2342d6/values @@ -7,7 +7,7 @@ creator: benf severity: minor -status: open +status: fixed summary: Address is outdated for FSF offices diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/body new file mode 100644 index 0000000..d3f00e7 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/body @@ -0,0 +1,25 @@ +Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: + +> the basic idea is to take a look at all public branches (for exaple +> all on lp/bitbucket/github) in order to tell the user of a +> webinterface that bug foo is fixed in branch xyz, and if its merged to +> the main branch + +I don't understand. The state of the bug in the main branch is right +there in the main branch; if it's not fixed there, it's not fixed there. +If it's merged in from a different branch, the bug state follows all the +other changes when they come in. + +Can you give an example of what would be done differently? + +-- + \ “The basic fact about human existence is not that it is a | + `\ tragedy, but that it is a bore.” —Henry L. Mencken | +_o__) | +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/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/values new file mode 100644 index 0000000..c3d2045 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/values @@ -0,0 +1,14 @@ +Alt-id: <874otjmjhr.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 23:34:08 +1000 + + +From: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7 + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/body new file mode 100644 index 0000000..1f6d84b --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/body @@ -0,0 +1,28 @@ +On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote: +> 1. is there any way to aggregate over multiple public branches in order +> to get the complete bug state + +Keeping the bug data with the source helps synchronize bug state and +source code. Bug state in branch A may not apply to branch B. Some +people like to weaken this source-bug linkage by keeping their bugs in +a branch all by themselves (ditz [http://ditz.rubyforge.org/] +currently supports this workflow). It sounds like you want to move +from "bugs with code" to "bugs and code in separate branches". We +don't have an easy way to do that in BE at the moment, since +version-control systems like Git have a single working branch at a +time (I think :p). What VCS are you using as a backend? + +> 2. is there any model for storing bigger files at a central place (for +> some of my bugs i have multi-megabyte tarballs attached) + + be comment ID "See the tarball at http://yourpage/something.tar.gz" +Then to grab the tarball, you'd use: + wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'` +to grab it. + +-- +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/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/values new file mode 100644 index 0000000..ed9c16f --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/values @@ -0,0 +1,14 @@ +Alt-id: <20090711125030.GA18185@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 08:50:30 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7 + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/body new file mode 100644 index 0000000..bd9e63a --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/body @@ -0,0 +1,25 @@ +Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: + +> 1. is there any way to aggregate over multiple public branches in +> order to get the complete bug state + +The bug state is as complete as the source code state. It's exactly as +aggregated as the rest of the source code; the “complete bug state” +would be the integration branch where you merge all the feature branches +and bug-fix branches together. + +If instead you want bugs to *not* be tightly linked with the rest of the +source code state, it seems you don't want a distributed bug tracker +like Bugs Everywhere. + +-- + \ “I cannot conceive that anybody will require multiplications at | + `\ the rate of 40,000 or even 4,000 per hour …” —F. H. Wales, 1936 | +_o__) | +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/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/values new file mode 100644 index 0000000..6958136 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/values @@ -0,0 +1,14 @@ +Alt-id: <878wivmjm1.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 23:31:34 +1000 + + +From: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7 + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/body new file mode 100644 index 0000000..11f344c --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/body @@ -0,0 +1,93 @@ +On Mon, Jul 13, 2009 at 09:05:34AM +0200, Ronny Pfannschmidt wrote: +> On Sun, 2009-07-12 at 19:55 -0400, W. Trevor King wrote: +> > On Sun, Jul 12, 2009 at 11:20:10PM +0200, Ronny Pfannschmidt wrote: +> > > On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote: +> > > > On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote: +> > > > > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote: +> > > > > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote: +> > > > > > > 2. is there any model for storing bigger files at a central place (for +> > > > > > > some of my bugs i have multi-megabyte tarballs attached) +> > > > > > +> > > > > > be comment ID "See the tarball at http://yourpage/something.tar.gz" +> > > > > > Then to grab the tarball, you'd use: +> > > > > > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'` +> > > > > > to grab it. +> > > > > +> > > > > so the basic idea is to do it completely self-managed +> > > > > and have have heterogenous sources of extended data? +> > > > +> > > > I assume "extended data" here refers to your tarballs. What sort of +> > > > homogenous source did you have in mind? The comment body is currently +> > > > just a binary blob for non-text/* types, otherwise it's text in +> > > > whatever encoding you've configured. +> > > +> > > some kind of common upload target for a single project in order to have +> > > more reliable sources of stuff thats related to bugs but doesnt fit into +> > > the normal repository +> > +> > Sorry, I'm still having trouble with "doesn't fit into the normal +> > repository". It's going to be large wherever you keep it. You +> > worried about multiple branches all having these big tarballs in them +> > and want a "lightweight" checkout without all the big +> > tarballs/whatever? I still think having some sort of "resources" +> > directory on an http server somewhere that you link to from comments +> > is the best plan. If you use the +> > be show --xml ID | be-xml-to-mbox | catmutt +> > approach, you can even write your comments in text/html and get +> > clickable links ;). A "push big file to remote and commit comment +> > linking to it" script would be pretty simple and keep everything +> > consistent. +> +> thats probably what i want to do + +#!/bin/bash +REMOTE_DIR="you@webhost:./public_html/bigfiles" +REMOTE_LINK="http://www.webhost.com/bigfiles" +if [ $# -ne 2 ]; then + echo "usage: $0 ID BIGFILE" + exit 1 +fi +ID="$1" +BIGFILE="$2" +be comment "$ID" "Large file stored at ${REMOTE_LINK}/${BIGFILE}" && scp "$BIGFILE" "${REMOTE_DIR}" + +> > > > On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote: +> > > > > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: +> > > > > +> > > > > > i want to see the combination of the bug data of all branches +> > > > > +> > > > > How is a tool to determine the set of “all branches”? The distributed +> > > > > VCS model means that set is indeterminate. +> > > > +> > > > He could just make a list of branches he likes. +> > > > +> > > > Ronny, are you looking to check bug status across several repos on the +> > > > fly, or periodically run something (with cron, etc.) to update a +> > > > static multi-repo summary? +> > > +> > > on the fly access +> > +> > Then listing bugs in a remote repo will either involve httping tons of +> > tiny values files for each bug (slow?) or running some hypothetical +> > BE-server locally for each repo speaking some BE-specific protocol +> > (complicated?). And how would you handle e.g. headless git repos, +> > where nothing's even checked out? +> > +> > You could always run the cron job every 15 minutes, and rely on +> > whatever VCS you're using having some intelligent protocol/procedure +> > to keep bandwidth down ;). If you need faster / more-efficient +> > updates, you'll probably need to throw out polling altogether and +> > setup all involved repos with a "push to central-repo on commit" hook +> > or some such. +> +> its intended to run on the place where i publish the repositories anyway + +Oh, you mean all the repos you want to cover are all _already_ on the +same host? + +-- +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/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/values new file mode 100644 index 0000000..d95deb9 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/values @@ -0,0 +1,14 @@ +Alt-id: <20090713104715.GA13723@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Mon, 13 Jul 2009 06:47:15 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 6dcc910a-ce15-4eeb-b49b-4747719748ed + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/body new file mode 100644 index 0000000..cf3c990 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/body @@ -0,0 +1,32 @@ +On Sat, Jul 11, 2009 at 11:25:07AM -0400, W. Trevor King wrote: +> The easiest implementation I can think of would be to keep local +> branches (on whatever computer is hosting your web interface) +> following your favorite repos. +> proxectX/ +> |-- repoA +> |-- repoB +> `-- repoC +> You'd pull upstream changes with a cron job. +> Listing bugs would be something along the lines of +> projectX$ for repo in * +> do +> pushd $repo +> be list +> popd +> done | sort | uniq +> ... + +I've reworked option handling for be, so my branch now supports + projectX$ for repo in * + do + be --dir $repo list + done | sort | uniq +etc. This also makes it easy to use your uninstalled development +version of be on any bug directory on your local machine. + +-- +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/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/values new file mode 100644 index 0000000..1c7b2bf --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/values @@ -0,0 +1,14 @@ +Alt-id: <20090713115734.GA13788@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Mon, 13 Jul 2009 07:57:34 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: bd98f525-95ec-446a-84e8-34c7d6fa5b40 + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/body new file mode 100644 index 0000000..c22de06 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/body @@ -0,0 +1,73 @@ +On Sun, Jul 12, 2009 at 11:20:10PM +0200, Ronny Pfannschmidt wrote: +> On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote: +> > On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote: +> > > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote: +> > > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote: +> > > > > 2. is there any model for storing bigger files at a central place (for +> > > > > some of my bugs i have multi-megabyte tarballs attached) +> > > > +> > > > be comment ID "See the tarball at http://yourpage/something.tar.gz" +> > > > Then to grab the tarball, you'd use: +> > > > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'` +> > > > to grab it. +> > > +> > > so the basic idea is to do it completely self-managed +> > > and have have heterogenous sources of extended data? +> > +> > I assume "extended data" here refers to your tarballs. What sort of +> > homogenous source did you have in mind? The comment body is currently +> > just a binary blob for non-text/* types, otherwise it's text in +> > whatever encoding you've configured. +> +> some kind of common upload target for a single project in order to have +> more reliable sources of stuff thats related to bugs but doesnt fit into +> the normal repository + +Sorry, I'm still having trouble with "doesn't fit into the normal +repository". It's going to be large wherever you keep it. You +worried about multiple branches all having these big tarballs in them +and want a "lightweight" checkout without all the big +tarballs/whatever? I still think having some sort of "resources" +directory on an http server somewhere that you link to from comments +is the best plan. If you use the + be show --xml ID | be-xml-to-mbox | catmutt +approach, you can even write your comments in text/html and get +clickable links ;). A "push big file to remote and commit comment +linking to it" script would be pretty simple and keep everything +consistent. + +> > On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote: +> > > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: +> > > +> > > > i want to see the combination of the bug data of all branches +> > > +> > > How is a tool to determine the set of “all branches”? The distributed +> > > VCS model means that set is indeterminate. +> > +> > He could just make a list of branches he likes. +> > +> > Ronny, are you looking to check bug status across several repos on the +> > fly, or periodically run something (with cron, etc.) to update a +> > static multi-repo summary? +> +> on the fly access + +Then listing bugs in a remote repo will either involve httping tons of +tiny values files for each bug (slow?) or running some hypothetical +BE-server locally for each repo speaking some BE-specific protocol +(complicated?). And how would you handle e.g. headless git repos, +where nothing's even checked out? + +You could always run the cron job every 15 minutes, and rely on +whatever VCS you're using having some intelligent protocol/procedure +to keep bandwidth down ;). If you need faster / more-efficient +updates, you'll probably need to throw out polling altogether and +setup all involved repos with a "push to central-repo on commit" hook +or some such. + +-- +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/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/values new file mode 100644 index 0000000..89f2724 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/values @@ -0,0 +1,14 @@ +Alt-id: <20090712235502.GA10782@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Sun, 12 Jul 2009 19:55:02 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 8ffc90d7-0be7-4b00-88e6-9ae1b65f7957 + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body new file mode 100644 index 0000000..6b7d3eb --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body @@ -0,0 +1,70 @@ +On Sun, 2009-07-12 at 19:55 -0400, W. Trevor King wrote: +> On Sun, Jul 12, 2009 at 11:20:10PM +0200, Ronny Pfannschmidt wrote: +> > On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote: +> > > On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote: +> > > > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote: +> > > > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote: +> > > > > > 2. is there any model for storing bigger files at a central place (for +> > > > > > some of my bugs i have multi-megabyte tarballs attached) +> > > > > +> > > > > be comment ID "See the tarball at http://yourpage/something.tar.gz" +> > > > > Then to grab the tarball, you'd use: +> > > > > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'` +> > > > > to grab it. +> > > > +> > > > so the basic idea is to do it completely self-managed +> > > > and have have heterogenous sources of extended data? +> > > +> > > I assume "extended data" here refers to your tarballs. What sort of +> > > homogenous source did you have in mind? The comment body is currently +> > > just a binary blob for non-text/* types, otherwise it's text in +> > > whatever encoding you've configured. +> > +> > some kind of common upload target for a single project in order to have +> > more reliable sources of stuff thats related to bugs but doesnt fit into +> > the normal repository +> +> Sorry, I'm still having trouble with "doesn't fit into the normal +> repository". It's going to be large wherever you keep it. You +> worried about multiple branches all having these big tarballs in them +> and want a "lightweight" checkout without all the big +> tarballs/whatever? I still think having some sort of "resources" +> directory on an http server somewhere that you link to from comments +> is the best plan. If you use the +> be show --xml ID | be-xml-to-mbox | catmutt +> approach, you can even write your comments in text/html and get +> clickable links ;). A "push big file to remote and commit comment +> linking to it" script would be pretty simple and keep everything +> consistent. +thats probably what i want to do + +> +> > > On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote: +> > > > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: +> > > > +> > > > > i want to see the combination of the bug data of all branches +> > > > +> > > > How is a tool to determine the set of “all branches”? The distributed +> > > > VCS model means that set is indeterminate. +> > > +> > > He could just make a list of branches he likes. +> > > +> > > Ronny, are you looking to check bug status across several repos on the +> > > fly, or periodically run something (with cron, etc.) to update a +> > > static multi-repo summary? +> > +> > on the fly access +> +> Then listing bugs in a remote repo will either involve httping tons of +> tiny values files for each bug (slow?) or running some hypothetical +> BE-server locally for each repo speaking some BE-specific protocol +> (complicated?). And how would you handle e.g. headless git repos, +> where nothing's even checked out? +> +> You could always run the cron job every 15 minutes, and rely on +> whatever VCS you're using having some intelligent protocol/procedure +> to keep bandwidth down ;). If you need faster / more-efficient +> updates, you'll probably need to throw out polling altogether and +> setup all involved repos with a "push to central-repo on commit" hook +> or some such. +its intended to run on the place where i publish the repositories anyway diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/values new file mode 100644 index 0000000..867700a --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/values @@ -0,0 +1,14 @@ +Alt-id: <1247468734.7189.1.camel@localhost> + + +Content-type: text/plain + + +Date: Mon, 13 Jul 2009 09:05:34 +0200 + + +From: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> + + +In-reply-to: 4d192c6c-a4a8-4844-b083-2dd5926bd2d9 + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/body new file mode 100644 index 0000000..2f2c16e --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/body @@ -0,0 +1,15 @@ +Hi, + +1. is there any way to aggregate over multiple public branches in order +to get the complete bug state + +2. is there any model for storing bigger files at a central place (for +some of my bugs i have multi-megabyte tarballs attached) + +Regards Ronny + + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/values new file mode 100644 index 0000000..38b8aa1 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/values @@ -0,0 +1,11 @@ +Alt-id: <1247313294.7701.60.camel@localhost> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 13:54:54 +0200 + + +From: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body new file mode 100644 index 0000000..debd486 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body @@ -0,0 +1,95 @@ +On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote: +> On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote: +> > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote: +> > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote: +> > > > 1. is there any way to aggregate over multiple public branches in order +> > > > to get the complete bug state +> > > +> > > Keeping the bug data with the source helps synchronize bug state and +> > > source code. Bug state in branch A may not apply to branch B. Some +> > > people like to weaken this source-bug linkage by keeping their bugs in +> > > a branch all by themselves (ditz [http://ditz.rubyforge.org/] +> > > currently supports this workflow). It sounds like you want to move +> > > from "bugs with code" to "bugs and code in separate branches". We +> > > don't have an easy way to do that in BE at the moment, since +> > > version-control systems like Git have a single working branch at a +> > > time (I think :p). What VCS are you using as a backend? +> > +> > the basic idea is to take a look at all public branches (for exaple all +> > on lp/bitbucket/github) in order to tell the user of a webinterface that +> > bug foo is fixed in branch xyz, and if its merged to the main branch +> +> Hmm. +> +> > > > 2. is there any model for storing bigger files at a central place (for +> > > > some of my bugs i have multi-megabyte tarballs attached) +> > > +> > > be comment ID "See the tarball at http://yourpage/something.tar.gz" +> > > Then to grab the tarball, you'd use: +> > > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'` +> > > to grab it. +> > so the basic idea is to do it completely self-managed +> +> Well, it's going to be managed by somebody ;). So far I'm not +> convinced enough for the manager to be me, so I'm suggesting it be you +> :p. +> +> > and have have heterogenous sources of extended data? +> +> I assume "extended data" here refers to your tarballs. What sort of +> homogenous source did you have in mind? The comment body is currently +> just a binary blob for non-text/* types, otherwise it's text in +> whatever encoding you've configured. +some kind of common upload target for a single project in order to have +more reliable sources of stuff thats related to bugs but doesnt fit into +the normal repository + + +> +> On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote: +> > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: +> > +> > > i want to see the combination of the bug data of all branches +> > +> > How is a tool to determine the set of “all branches”? The distributed +> > VCS model means that set is indeterminate. +> +> He could just make a list of branches he likes. +> +> Ronny, are you looking to check bug status across several repos on the +> fly, or periodically run something (with cron, etc.) to update a +> static multi-repo summary? +on the fly access + +> +> The easiest implementation I can think of would be to keep local +> branches (on whatever computer is hosting your web interface) +> following your favorite repos. +> proxectX/ +> |-- repoA +> |-- repoB +> `-- repoC +> You'd pull upstream changes with a cron job. +> Listing bugs would be something along the lines of +> projectX$ for repo in * +> do +> pushd $repo +> be list +> popd +> done | sort | uniq +> Then to show bug status you would have something like +> projectX$ for repo in * +> do +> echo $repo +> pushd $repo +> be show ${BUGID} +> popd +> done +> For a web frontend, you'd want to translate that to python/libbe. +> + +yes, the idea is to get a web fontend for multiple branches +and maybe a local gtk fontend for local multi-branch setups + +for some of my projects i have n local and m remote repos, and merging +is not always intended soonish diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values new file mode 100644 index 0000000..de585ee --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values @@ -0,0 +1,14 @@ +Alt-id: <1247433610.14803.3.camel@localhost> + + +Content-type: text/plain + + +Date: Sun, 12 Jul 2009 23:20:10 +0200 + + +From: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> + + +In-reply-to: bd98f525-95ec-446a-84e8-34c7d6fa5b40 + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body new file mode 100644 index 0000000..5f55127 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body @@ -0,0 +1,87 @@ +On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote: +> On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote: +> > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote: +> > > 1. is there any way to aggregate over multiple public branches in order +> > > to get the complete bug state +> > +> > Keeping the bug data with the source helps synchronize bug state and +> > source code. Bug state in branch A may not apply to branch B. Some +> > people like to weaken this source-bug linkage by keeping their bugs in +> > a branch all by themselves (ditz [http://ditz.rubyforge.org/] +> > currently supports this workflow). It sounds like you want to move +> > from "bugs with code" to "bugs and code in separate branches". We +> > don't have an easy way to do that in BE at the moment, since +> > version-control systems like Git have a single working branch at a +> > time (I think :p). What VCS are you using as a backend? +> +> the basic idea is to take a look at all public branches (for exaple all +> on lp/bitbucket/github) in order to tell the user of a webinterface that +> bug foo is fixed in branch xyz, and if its merged to the main branch + +Hmm. + +> > > 2. is there any model for storing bigger files at a central place (for +> > > some of my bugs i have multi-megabyte tarballs attached) +> > +> > be comment ID "See the tarball at http://yourpage/something.tar.gz" +> > Then to grab the tarball, you'd use: +> > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'` +> > to grab it. +> so the basic idea is to do it completely self-managed + +Well, it's going to be managed by somebody ;). So far I'm not +convinced enough for the manager to be me, so I'm suggesting it be you +:p. + +> and have have heterogenous sources of extended data? + +I assume "extended data" here refers to your tarballs. What sort of +homogenous source did you have in mind? The comment body is currently +just a binary blob for non-text/* types, otherwise it's text in +whatever encoding you've configured. + +On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote: +> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: +> +> > i want to see the combination of the bug data of all branches +> +> How is a tool to determine the set of “all branches”? The distributed +> VCS model means that set is indeterminate. + +He could just make a list of branches he likes. + +Ronny, are you looking to check bug status across several repos on the +fly, or periodically run something (with cron, etc.) to update a +static multi-repo summary? + +The easiest implementation I can think of would be to keep local +branches (on whatever computer is hosting your web interface) +following your favorite repos. + proxectX/ + |-- repoA + |-- repoB + `-- repoC +You'd pull upstream changes with a cron job. +Listing bugs would be something along the lines of + projectX$ for repo in * + do + pushd $repo + be list + popd + done | sort | uniq +Then to show bug status you would have something like + projectX$ for repo in * + do + echo $repo + pushd $repo + be show ${BUGID} + popd + done +For a web frontend, you'd want to translate that to python/libbe. + +-- +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/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/values new file mode 100644 index 0000000..2792f2b --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/values @@ -0,0 +1,14 @@ +Alt-id: <20090711152507.GA18461@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 11:25:07 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: e520239c-8d69-4ff6-b1bd-0c2f74366200 + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/body new file mode 100644 index 0000000..cc3cff3 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/body @@ -0,0 +1,37 @@ +On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote: +> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: +> +> > i want to see the combination of the bug data of all branches +> +> What is your definition of ???all branches???? When I'm working with +> distributed VCS, I create branches wherever I feel like, and the VCS +> tool doesn't have some central registry of branches to keep up to date. +> +> How is a tool to determine the set of ???all branches???? The distributed +> VCS model means that set is indeterminate. + +In the first main Ronny spoke about "public" branches. To me it means that +if a branch is public, he should like to have a status of that branch. + +We all agree (probably ;-) ) that tha main branch is the "right" branch, but +as I see it, Ronny's question has some logic. +I'd like to know that a certain bug is fixed in a certain branch, also if it +is still not merged in the main branch, for various reason (ie I am interested +in the solution since the bug stop my work) + +Imagine it like a rss feed aggregator: in one place there are all the bugs of +all the branches that the developers make avaible to the public with +a repository. This can make easier the life to who want to try a something +since he know what branch he must check out, instead of checking all the +branch he can find to test if he get what is looking for. + +Unluckyly I have no idea how to solve it. :-( + +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/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/values new file mode 100644 index 0000000..5e3db52 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/values @@ -0,0 +1,14 @@ +Alt-id: <20090713085859.GA21800@grys.it> + + +Content-type: text/plain + + +Date: Mon, 13 Jul 2009 10:58:59 +0200 + + +From: Gianluca Montecchi <gian@grys.it> + + +In-reply-to: e520239c-8d69-4ff6-b1bd-0c2f74366200 + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/body new file mode 100644 index 0000000..93f082b --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/body @@ -0,0 +1,33 @@ +On Sat, 2009-07-11 at 23:34 +1000, Ben Finney wrote: +> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: +> +> > the basic idea is to take a look at all public branches (for exaple +> > all on lp/bitbucket/github) in order to tell the user of a +> > webinterface that bug foo is fixed in branch xyz, and if its merged to +> > the main branch +> +> I don't understand. The state of the bug in the main branch is right +> there in the main branch; if it's not fixed there, it's not fixed there. +> If it's merged in from a different branch, the bug state follows all the +> other changes when they come in. +> +> Can you give an example of what would be done differently? +> +i want to see the combination of the bug data of all branches + +for example + +i got bug +its fixed in the branch "something" +its not fixed/merged to "main" + +now something like a website should tell me, this bug has been fixed in +branch xyz and the fix is not yet merged into main + + + + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/values new file mode 100644 index 0000000..789fd7f --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/values @@ -0,0 +1,14 @@ +Alt-id: <1247320857.7701.67.camel@localhost> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 16:00:57 +0200 + + +From: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> + + +In-reply-to: 0f60a148-7024-44bd-bbed-377cbece9d1b + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/body new file mode 100644 index 0000000..3b417be --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/body @@ -0,0 +1,27 @@ +On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote: +> On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote: +> > 1. is there any way to aggregate over multiple public branches in order +> > to get the complete bug state +> +> Keeping the bug data with the source helps synchronize bug state and +> source code. Bug state in branch A may not apply to branch B. Some +> people like to weaken this source-bug linkage by keeping their bugs in +> a branch all by themselves (ditz [http://ditz.rubyforge.org/] +> currently supports this workflow). It sounds like you want to move +> from "bugs with code" to "bugs and code in separate branches". We +> don't have an easy way to do that in BE at the moment, since +> version-control systems like Git have a single working branch at a +> time (I think :p). What VCS are you using as a backend? +the basic idea is to take a look at all public branches (for exaple all +on lp/bitbucket/github) in order to tell the user of a webinterface that +bug foo is fixed in branch xyz, and if its merged to the main branch +> +> > 2. is there any model for storing bigger files at a central place (for +> > some of my bugs i have multi-megabyte tarballs attached) +> +> be comment ID "See the tarball at http://yourpage/something.tar.gz" +> Then to grab the tarball, you'd use: +> wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'` +> to grab it. +so the basic idea is to do it completely self-managed and have have +heterogenous sources of extended data? diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/values new file mode 100644 index 0000000..43173a4 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/values @@ -0,0 +1,14 @@ +Alt-id: <1247317985.7701.63.camel@localhost> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 15:13:05 +0200 + + +From: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> + + +In-reply-to: 13012b22-2d02-444c-87c0-8cf0f17137ae + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/body new file mode 100644 index 0000000..0263fbb --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/body @@ -0,0 +1,22 @@ +Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: + +> i want to see the combination of the bug data of all branches + +What is your definition of “all branches”? When I'm working with +distributed VCS, I create branches wherever I feel like, and the VCS +tool doesn't have some central registry of branches to keep up to date. + +How is a tool to determine the set of “all branches”? The distributed +VCS model means that set is indeterminate. + +-- + \ “Pinky, are you pondering what I'm pondering?” “I think so, | + `\ Brain, but I find scratching just makes it worse.” —_Pinky and | +_o__) The Brain_ | +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/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/values new file mode 100644 index 0000000..351fdb9 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/values @@ -0,0 +1,14 @@ +Alt-id: <87zlbbl128.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Sun, 12 Jul 2009 00:57:35 +1000 + + +From: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7 + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/body new file mode 100644 index 0000000..9fb10bc --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/body @@ -0,0 +1,26 @@ +On Sat, Jul 11, 2009 at 11:31:34PM +1000, Ben Finney wrote: +> Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes: +> +> > 1. is there any way to aggregate over multiple public branches in +> > order to get the complete bug state +> +> The bug state is as complete as the source code state. It's exactly as +> aggregated as the rest of the source code; the ???complete bug state??? +> would be the integration branch where you merge all the feature branches +> and bug-fix branches together. +> +> If instead you want bugs to *not* be tightly linked with the rest of the +> source code state, it seems you don't want a distributed bug tracker +> like Bugs Everywhere. + +"the complete bug state" probably means that he want to know (and in some way +to publish it) that the bug "xyz" is fixed and merged in main while bug "abc" +is fixed but only in branch "123" and bug "def" is still open in branch "456" + +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/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/values new file mode 100644 index 0000000..a7c438b --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/values @@ -0,0 +1,14 @@ +Alt-id: <20090713090341.GB21800@grys.it> + + +Content-type: text/plain + + +Date: Mon, 13 Jul 2009 11:03:41 +0200 + + +From: Gianluca Montecchi <gian@grys.it> + + +In-reply-to: 1f9f60de-ba37-42bc-a1c0-dc062ef255e1 + diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/values new file mode 100644 index 0000000..2a3c4f3 --- /dev/null +++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/values @@ -0,0 +1,17 @@ +creator: W. Trevor King <wking@drexel.edu> + + +reporter: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> + + +severity: wishlist + + +status: unconfirmed + + +summary: Bug aggregation. Multi-repo meta-BE? + + +time: Tue, 21 Jul 2009 18:32:12 +0000 + diff --git a/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/4952e1c7-e035-42f1-882b-6b5264481d0a/body b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/4952e1c7-e035-42f1-882b-6b5264481d0a/body new file mode 100644 index 0000000..c799630 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/4952e1c7-e035-42f1-882b-6b5264481d0a/body @@ -0,0 +1,47 @@ +On Sunday 19 July 2009 00:00:46 Chris Ball wrote: +> Hi, +> +> > For example, let's assume we have target a, b, c There is a way +> > to know that "a" is a past target, "b" is the current target and +> > "c" is a future target ? +> +> We could add a "date due" field for each target. + +Good idea + +> > More: there is a way to know if a target is closed or open ? +> +> We could add a "target close" operation that moves all open bugs +> assigned to one target to the next date-due target. + +Nice. But instead of moving all bugs to the next date-due target, I'd prefer +to leave the choice to the user + + +> I see problems with these ideas in general, because we're assuming +> agreement by all parties/branches on when a target's date due is. +> Maybe it's okay to demand that social conventions be used to handle +> such a disagreement, or maybe not. + +I don't see these as problems per se. We can have two cases: + +1) a personal branch (like my html output or Trevor's email interface). In +this case there is not any problem to decide the due date + +2) a branch with a group of delopers (let it be the canonical branch o an +experimental branch): in this case I suppose that working together means to be +able to agree on some things + +In any case, having the possibility to set a due date does not means that it +is obligatory to do it and should be a good idea to offer as many possibilities +as we can to the users of BE + +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/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/4952e1c7-e035-42f1-882b-6b5264481d0a/values b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/4952e1c7-e035-42f1-882b-6b5264481d0a/values new file mode 100644 index 0000000..db30358 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/4952e1c7-e035-42f1-882b-6b5264481d0a/values @@ -0,0 +1,14 @@ +Alt-id: <200907202259.11774.gian@grys.it> + + +Content-type: text/plain + + +Date: Mon, 20 Jul 2009 22:59:11 +0200 + + +From: Gianluca Montecchi <gian@grys.it> + + +In-reply-to: 6555a651-5a7f-4a8a-9793-47ad1315e9e8 + diff --git a/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/6555a651-5a7f-4a8a-9793-47ad1315e9e8/body b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/6555a651-5a7f-4a8a-9793-47ad1315e9e8/body new file mode 100644 index 0000000..ef09dc0 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/6555a651-5a7f-4a8a-9793-47ad1315e9e8/body @@ -0,0 +1,26 @@ +Hi, + + > For example, let's assume we have target a, b, c There is a way + > to know that "a" is a past target, "b" is the current target and + > "c" is a future target ? + +We could add a "date due" field for each target. + + > More: there is a way to know if a target is closed or open ? + +We could add a "target close" operation that moves all open bugs +assigned to one target to the next date-due target. + +I see problems with these ideas in general, because we're assuming +agreement by all parties/branches on when a target's date due is. +Maybe it's okay to demand that social conventions be used to handle +such a disagreement, or maybe not. + +- 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/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/6555a651-5a7f-4a8a-9793-47ad1315e9e8/values b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/6555a651-5a7f-4a8a-9793-47ad1315e9e8/values new file mode 100644 index 0000000..cdf7754 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/6555a651-5a7f-4a8a-9793-47ad1315e9e8/values @@ -0,0 +1,14 @@ +Alt-id: <m3skgt648h.fsf@pullcord.laptop.org> + + +Content-type: text/plain + + +Date: Sat, 18 Jul 2009 18:00:46 -0400 + + +From: Chris Ball <cjb@laptop.org> + + +In-reply-to: b9865d8b-46ae-4169-bc83-d75a98164729 + diff --git a/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/7750d77c-85d2-4810-9d41-cec62b0da885/body b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/7750d77c-85d2-4810-9d41-cec62b0da885/body new file mode 100644 index 0000000..874d906 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/7750d77c-85d2-4810-9d41-cec62b0da885/body @@ -0,0 +1,20 @@ +On Monday 20 July 2009 23:03:18 Chris Ball wrote: +> Hi Gianluca, +> +> > In any case, having the possibility to set a due date does not +> > means that it is obligatory to do it and should be a good idea to +> > offer as many possibilities as we can to the users of BE +> +> Okay, sounds reasonable. Would you like to write a patch for +> associating due dates and open/closed with a target? + +Ok. As soon as I finish a basic implementation of the html export, I will be +glad to try to write a patch. + +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/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/7750d77c-85d2-4810-9d41-cec62b0da885/values b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/7750d77c-85d2-4810-9d41-cec62b0da885/values new file mode 100644 index 0000000..d830558 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/7750d77c-85d2-4810-9d41-cec62b0da885/values @@ -0,0 +1,14 @@ +Alt-id: <200907202340.39963.gian@grys.it> + + +Content-type: text/plain + + +Date: Mon, 20 Jul 2009 23:40:39 +0200 + + +From: Gianluca Montecchi <gian@grys.it> + + +In-reply-to: 777182da-a216-45c7-bf4d-42c84e511c66 + diff --git a/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/777182da-a216-45c7-bf4d-42c84e511c66/body b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/777182da-a216-45c7-bf4d-42c84e511c66/body new file mode 100644 index 0000000..13505c1 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/777182da-a216-45c7-bf4d-42c84e511c66/body @@ -0,0 +1,19 @@ +Hi Gianluca, + + > In any case, having the possibility to set a due date does not + > means that it is obligatory to do it and should be a good idea to + > offer as many possibilities as we can to the users of BE + +Okay, sounds reasonable. Would you like to write a patch for +associating due dates and open/closed with a target? + +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/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/777182da-a216-45c7-bf4d-42c84e511c66/values b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/777182da-a216-45c7-bf4d-42c84e511c66/values new file mode 100644 index 0000000..a14e287 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/777182da-a216-45c7-bf4d-42c84e511c66/values @@ -0,0 +1,14 @@ +Alt-id: <m3hbx72hk9.fsf@pullcord.laptop.org> + + +Content-type: text/plain + + +Date: Mon, 20 Jul 2009 17:03:18 -0400 + + +From: Chris Ball <cjb@laptop.org> + + +In-reply-to: 4952e1c7-e035-42f1-882b-6b5264481d0a + diff --git a/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/9bbe9370-99c7-4d7c-80ee-9ade6b6feb9f/body b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/9bbe9370-99c7-4d7c-80ee-9ade6b6feb9f/body new file mode 100644 index 0000000..a916904 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/9bbe9370-99c7-4d7c-80ee-9ade6b6feb9f/body @@ -0,0 +1,37 @@ +On Sat, Jul 18, 2009 at 06:00:46PM -0400, Chris Ball wrote: +> > For example, let's assume we have target a, b, c There is a way +> > to know that "a" is a past target, "b" is the current target and +> > "c" is a future target ? +> +> We could add a "date due" field for each target. + +Another option would be a "blocked by" field, since you might miss +deadlines, or have parallel targeted branches. Or just pick target +names following some scheme so the alphanumeric-sort is also a +dependency-order sort ;). + +> > More: there is a way to know if a target is closed or open ? + +There's also + $ be list --target 0.1 +If there are active bugs, the target is open. Otherwise, you must have +made it ;). + +> We could add a "target close" operation that moves all open bugs +> assigned to one target to the next date-due target. + +for bug in `be list --target 0.1 --uuids`; do + be target $bug $NEXT_TARGET +done + +To avoid the loop, we could change status, severity, target, etc from + be COMMAND BUG ARG +to + be COMMAND ARG BUG [MORE BUGS ...] + +-- +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/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/9bbe9370-99c7-4d7c-80ee-9ade6b6feb9f/values b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/9bbe9370-99c7-4d7c-80ee-9ade6b6feb9f/values new file mode 100644 index 0000000..b6c0979 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/9bbe9370-99c7-4d7c-80ee-9ade6b6feb9f/values @@ -0,0 +1,14 @@ +Alt-id: <20090718222701.GA304@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Sat, 18 Jul 2009 18:27:01 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 6555a651-5a7f-4a8a-9793-47ad1315e9e8 + diff --git a/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/b9865d8b-46ae-4169-bc83-d75a98164729/body b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/b9865d8b-46ae-4169-bc83-d75a98164729/body new file mode 100644 index 0000000..7382bae --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/b9865d8b-46ae-4169-bc83-d75a98164729/body @@ -0,0 +1,20 @@ +Hello + +Just a question and only for curiosity: there is an easy way to determine the +target succession ? + +For example, let's assume we have target a, b, c +There is a way to know that "a" is a past target, "b" is the current target +and "c" is a future target ? More: there is a way to know if a target is +closed or open ? + +thanks + +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/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/b9865d8b-46ae-4169-bc83-d75a98164729/values b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/b9865d8b-46ae-4169-bc83-d75a98164729/values new file mode 100644 index 0000000..4972040 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/comments/b9865d8b-46ae-4169-bc83-d75a98164729/values @@ -0,0 +1,11 @@ +Alt-id: <200907182351.03217.gian@grys.it> + + +Content-type: text/plain + + +Date: Sat, 18 Jul 2009 23:51:03 +0200 + + +From: Gianluca Montecchi <gian@grys.it> + diff --git a/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/values b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/values new file mode 100644 index 0000000..1485877 --- /dev/null +++ b/.be/bugs/22b6f620-d2f7-42a5-a02e-145733a4e366/values @@ -0,0 +1,20 @@ +assigned: Gianluca Montecchi <gian@grys.it> + + +creator: W. Trevor King <wking@drexel.edu> + + +reporter: Gianluca Montecchi <gian@grys.it> + + +severity: wishlist + + +status: assigned + + +summary: Sorting targets chronologically + + +time: Tue, 21 Jul 2009 18:34:25 +0000 + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/body new file mode 100644 index 0000000..5ce4f1c --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/body @@ -0,0 +1,23 @@ +"W. Trevor King" <wking@drexel.edu> writes: + +> On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote: +> > Instead of a separate command for each output format, could we have +> > a single "produce a static report of the bug database" command, and +> > specify output format as an option? +> > […] +> +> Do people like this architecture better than my be-xml-to-mbox +> approach? + +I think this question is illuminated by the related question: Is mbox +output a static report, or another read-write data store? + +It can technically be both, of course, which is why the question may be +helpful: it may help show what is the *conceptual* purpose of the mbox +output format for Bugs Everywhere. + +-- + \ “Time is the great legalizer, even in the field of morals.” | + `\ —Henry L. Mencken | +_o__) | +Ben Finney diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/values new file mode 100644 index 0000000..b83f4a6 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/values @@ -0,0 +1,14 @@ +Alt-id: <87hbxqrckv.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Mon, 06 Jul 2009 08:26:24 +1000 + + +From: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/body new file mode 100644 index 0000000..dbf3b1b --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/body @@ -0,0 +1,47 @@ +Gianluca Montecchi <gian@grys.it> writes: + +> 1) is it ok to develop this command ? I know that this is not a fully +> featured web interface, but I am sure that it can be usefull. + +Yes, definitely. I can see it being a very easy way to put one's bug +database online for browsing. + +> I am open to suggestion about it of course. + +Instead of a separate command for each output format, could we have a +single “produce a static report of the bug database” command, and +specify output format as an option? + +How about: + + be report + be report --format ascii + be report --format rst + be report --format html + +Where the ‘--format’ option has a default of, e.g., “ascii”. + +This would mean that you are implementing the ‘html’ format of this +putative command. + +> 2) I see that every command is implemented with a python file in the +> becommand dir. For a better code, I'd like to split the command +> implementation into two files: a file that contain the actual code and +> a second file that have the html related part, any problem with this ? + +This sounds quite sensible to me. The existence of a command implies a +module of the same name in ‘becommand’, but there's no necessary +implication that that module can't import modules from elsewhere to do +its work. + +-- + \ “It ain't so much the things we don't know that get us in | + `\ trouble. It's the things we know that ain't so.” —Artemus Ward | +_o__) (1834–1867), U.S. journalist | +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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/values new file mode 100644 index 0000000..4ef9544 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/values @@ -0,0 +1,14 @@ +Alt-id: <87y6r5qoyw.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Sat, 04 Jul 2009 10:19:35 +1000 + + +From: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/body new file mode 100644 index 0000000..4276b9c --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/body @@ -0,0 +1,25 @@ +Gianluca Montecchi <gian@grys.it> writes: + +> On Monday 06 July 2009 12:48:39 W. Trevor King wrote: +> > Gianluca is clearly thinking about a static report [for a collection +> > of HTML files as output]: +> +> You are right, static, but not exactly a report as I think Ben is +> thinking + +I think it exactly is a report: multiple, static, browseable pages +reporting the state of the database at a point in time. + +What makes you think that term doesn't apply? + +-- + \ “The problem with television is that the people must sit and | + `\ keep their eyes glued on a screen: the average American family | +_o__) hasn't time for it.” —_The New York Times_, 1939 | +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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/values new file mode 100644 index 0000000..7dee5d6 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/values @@ -0,0 +1,14 @@ +Alt-id: <87skh9p8ax.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Tue, 07 Jul 2009 11:53:58 +1000 + + +From: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/body new file mode 100644 index 0000000..8451bd7 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/body @@ -0,0 +1,50 @@ +On Mon, Jul 06, 2009 at 08:26:24AM +1000, Ben Finney wrote: +> "W. Trevor King" <wking@drexel.edu> writes: +> +> > On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote: +> > > Instead of a separate command for each output format, could we have +> > > a single "produce a static report of the bug database" command, and +> > > specify output format as an option? +> > +> > Do people like this architecture better than my be-xml-to-mbox +> > approach? +> +> I think this question is illuminated by the related question: Is mbox +> output a static report, or another read-write data store? + +Gianluca is clearly thinking about a static report: + +On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote: +> The goal is to be able to do something like "be html /web/page" to have in the +> /web/page directory some static html pages that basically are the dump of the +> be repository, much like ditz have + +I think truly interactive frontends like Steve's working on need to be +build on top of libbe directly, since they'll need to make lots of +small changes to the database, and it's to slow to be reloading the +database for every change. Static dumps like my mbox or Gianluca's +html could just parse the xml output of `be list' and other be +commands. + +There should also be an xml import for `be new' and `be comment' so +you could import new bugs/comments from whatever format after writing +a whatever->xml converter. This would allow you to email new bugs and +comments to the database (e.g. via some procmail-spawned +be-parse-email script) which would give you some level of +interactivity, but you'd have to regenerate your mbox to see your new +comments in your mail reader. + +I think interactive use that gives you live-updates in your mail +reader isn't worth the trouble, since you'd need to teach BE imap or +smtp+mbox-locking. Hmm, maybe it smtp+mbox-locking wouldn't be so bad, +but that would be a distinct frontend project like Steve's, not part +of the becommands. + +Trevor + +-- +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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/values new file mode 100644 index 0000000..6f9ecf7 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/values @@ -0,0 +1,14 @@ +Alt-id: <20090706104839.GA19537@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Mon, 6 Jul 2009 06:48:39 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 074ef29a-3f1d-46dc-8561-7a56af7e6d67 + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/body new file mode 100644 index 0000000..3b53533 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/body @@ -0,0 +1,23 @@ +On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote: +> Instead of a separate command for each output format, could we have a +> single "produce a static report of the bug database" command, and +> specify output format as an option? +> +> How about: +> +> be report +> be report --format ascii +> be report --format rst +> be report --format html + +Do people like this architecture better than my be-xml-to-mbox +approach? I think the tradeoff is easy output format implementation +vs cluttered core codebase. Should we use both, depending on how +useful people think the output format will be? + +-- +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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/values new file mode 100644 index 0000000..3452022 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/values @@ -0,0 +1,14 @@ +Alt-id: <20090705143108.GB10709@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Sun, 5 Jul 2009 10:31:08 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 1dba8196-654b-4ca0-9a95-fb334af81863 + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/body new file mode 100644 index 0000000..9bf3851 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/body @@ -0,0 +1,123 @@ +On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote: +> +> Hello to everyone +> +> As i said in a previous mail, I am working on a "html" command for be. +> The goal is to be able to do something like "be html /web/page" to have in the +> /web/page directory some static html pages that basically are the dump of the +> be repository, much like ditz have +> This will enable a simple and fast publish of the bus list and details on the +> web, at least in read only mode. +> +> So I'd like to ask some question: +> 1) is it ok to develop this command ? I know that this is not a fully featured +> web interface, but I am sure that it can be usefull. +> +> I am open to suggestion about it of course. +> +> 2) I see that every command is implemented with a python file in the becommand +> dir. For a better code, I'd like to split the command implementation into two +> files: a file that contain the actual code and a second file that have the html +> related part, any problem with this ? I don't like to have the html part and +> the code part in one big and unreadable file. +> +> I'd like to hear other opinion about this. +> +> Thanks for now +> bye +> Gianluca +> +> +> _______________________________________________ +> Be-devel mailing list +> Be-devel@bugseverywhere.org +> http://void.printf.net/cgi-bin/mailman/listinfo/be-devel + +On Mon, Jul 06, 2009 at 10:18:33PM +0200, Gianluca Montecchi wrote: +> This sound like an interesting idea, but what i'd like to do is not, strictly +> speaking, a report. It is a full tree of html pages that are browseable, both +> on line and offline + +I'm not sure what distinction you're making about "report". You're +just producing a static snapshot of the current database status, +right? The number of pages and completeness of coverage are nice, but +it's still a static entity generated from a particular snapshot, which +is what I mean by "report" ;). + +> > > 2) I see that every command is implemented with a python file in the +> > > becommand dir. For a better code, I'd like to split the command +> > > implementation into two files: a file that contain the actual code and +> > > a second file that have the html related part, any problem with this ? +> > +> > This sounds quite sensible to me. The existence of a command implies a +> > module of the same name in ‘becommand’, but there's no necessary +> > implication that that module can't import modules from elsewhere to do +> > its work. +> +> The "elsewhere" for now is the same directory, just another module +> + +On Mon, Jul 06, 2009 at 10:38:56PM +0200, Gianluca Montecchi wrote: +> > On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote: +> > > The goal is to be able to do something like "be html /web/page" to have +> > > in the /web/page directory some static html pages that basically are the +> > > dump of the be repository, much like ditz have +> > +> > I think truly interactive frontends like Steve's working on need to be +> > build on top of libbe directly, since they'll need to make lots of +> > small changes to the database, and it's to slow to be reloading the +> > database for every change. Static dumps like my mbox or Gianluca's +> > html could just parse the xml output of `be list' and other be +> > commands. +> +> Ok, but if I want to have an html dump that is browseable, I need to parse the +> xml. Am I correct ? +> If yes, should not be easiear to use directly the libbe ? + +Using libbe directly is easier, but also more tightly tied to the be +internals which could weigh down future refactoring. Partly I'm +afraid of our 2.5 different html-output mechanisms. Either their +should be a single Right Way that tries to satisfy everyone, or a +smorgasbord of loosely coupled translators, so it's not so painful to +kill them if/when they go out of style :p. + +On Mon, Jul 06, 2009 at 10:46:54PM +0200, Gianluca Montecchi wrote: +> On Saturday 04 July 2009 02:31:26 Chris Ball wrote: +> > It might be a good idea for "be html" to use the CherryPy web interface +> > that Steve is working on. The command could start up the CherryPy app +> > and scrape all of the available pages to get a stand-alone dump; this +> > would avoid having to keep two (okay, more than two at this point) +> > separate sets of HTML templates in the source tree. What do you think? +> +> It can be do, but this implies that CherryPy must be installed and configured, +> a thing that I don't want to impose. My idea is to offer a simpler way to have +> some html pages, where you just need to have BE installed. + +I agree that not needing CherryPy for a static html dump is good. +Also, read-only templates will look different from the CherryPy +interactive templates. +1 for another quasi-redundant template set +;). + +> > > 2) I see that every command is implemented with a python file in +> > > the becommand dir. For a better code, I'd like to split the +> > > command implementation into two files: a file that contain the +> > > actual code and a second file that have the html related part, +> > > any problem with this ? I don't like to have the html part and +> > > the code part in one big and unreadable file. +> > +> > I agree that becommands/*.py commands should not contain any HTML +> > layout code. Putting it somewhere else instead sounds fine. +> +> I am in doubt with the "somewhere else", since for now I put the html template +> into a separate file in the same directory. Suggestion ? + +I think that only code intended only for command line use only should +go into becommands, but really, just dump it anywhere and we can shift +it around later :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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/values new file mode 100644 index 0000000..ac3b5ab --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/values @@ -0,0 +1,14 @@ +Alt-id: <20090707013454.GA3721@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Mon, 6 Jul 2009 21:34:54 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: da97e18f-33d6-469e-9d93-6457b9a6bfca + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/body new file mode 100644 index 0000000..2301eba --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/body @@ -0,0 +1,47 @@ +On Saturday 04 July 2009 02:19:35 Ben Finney wrote: +> Gianluca Montecchi <gian@grys.it> writes: + +> +> > I am open to suggestion about it of course. +> +> Instead of a separate command for each output format, could we have a +> single “produce a static report of the bug database” command, and +> specify output format as an option? +> +> How about: +> +> be report +> be report --format ascii +> be report --format rst +> be report --format html +> +> Where the ‘--format’ option has a default of, e.g., “ascii”. +> +> This would mean that you are implementing the ‘html’ format of this +> putative command. +> + +This sound like an interesting idea, but what i'd like to do is not, strictly +speaking, a report. It is a full tree of html pages that are browseable, both +on line and offline + +> > 2) I see that every command is implemented with a python file in the +> > becommand dir. For a better code, I'd like to split the command +> > implementation into two files: a file that contain the actual code and +> > a second file that have the html related part, any problem with this ? +> +> This sounds quite sensible to me. The existence of a command implies a +> module of the same name in ‘becommand’, but there's no necessary +> implication that that module can't import modules from elsewhere to do +> its work. + +The "elsewhere" for now is the same directory, just another module + +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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/values new file mode 100644 index 0000000..6259717 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/values @@ -0,0 +1,14 @@ +Alt-id: <200907062218.33895.gian@grys.it> + + +Content-type: text/plain + + +Date: Mon, 06 Jul 2009 22:18:33 +0200 + + +From: Gianluca Montecchi <gian@grys.it> + + +In-reply-to: 1dba8196-654b-4ca0-9a95-fb334af81863 + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/body new file mode 100644 index 0000000..50a30e8 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/body @@ -0,0 +1,35 @@ +Hi Gianluca, + + > As i said in a previous mail, I am working on a "html" command + > for be. The goal is to be able to do something like "be html + > /web/page" to have in the /web/page directory some static html + > pages that basically are the dump of the be repository, much like + > ditz have. This will enable a simple and fast publish of the bus + > list and details on the web, at least in read only mode. + +It might be a good idea for "be html" to use the CherryPy web interface +that Steve is working on. The command could start up the CherryPy app +and scrape all of the available pages to get a stand-alone dump; this +would avoid having to keep two (okay, more than two at this point) +separate sets of HTML templates in the source tree. What do you think? + + > 2) I see that every command is implemented with a python file in + > the becommand dir. For a better code, I'd like to split the + > command implementation into two files: a file that contain the + > actual code and a second file that have the html related part, + > any problem with this ? I don't like to have the html part and + > the code part in one big and unreadable file. + +I agree that becommands/*.py commands should not contain any HTML +layout code. Putting it somewhere else instead sounds fine. + +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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/values new file mode 100644 index 0000000..7d09f96 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/values @@ -0,0 +1,14 @@ +Alt-id: <m3iqi9thk1.fsf@pullcord.laptop.org> + + +Content-type: text/plain + + +Date: Fri, 03 Jul 2009 20:31:26 -0400 + + +From: Chris Ball <cjb@laptop.org> + + +In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body new file mode 100644 index 0000000..8991cfb --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body @@ -0,0 +1,93 @@ +> On Mon, Jul 06, 2009 at 10:18:33PM +0200, Gianluca Montecchi wrote: +>> This sound like an interesting idea, but what i'd like to do is not, +>> strictly +>> speaking, a report. It is a full tree of html pages that are browseable, +>> both +>> on line and offline +> +> I'm not sure what distinction you're making about "report". You're +> just producing a static snapshot of the current database status, +> right? The number of pages and completeness of coverage are nice, but +> it's still a static entity generated from a particular snapshot, which +> is what I mean by "report" ;). + +Mmm, my bad here. +I normally speak about "report" as something that is not browseable, like +the output of a report generator (reportlab or whatever), but I admit that +basically also the html output I am working on is a report. + + +> On Mon, Jul 06, 2009 at 10:38:56PM +0200, Gianluca Montecchi wrote: +>> +>> Ok, but if I want to have an html dump that is browseable, I need to +>> parse the +>> xml. Am I correct ? +>> If yes, should not be easiear to use directly the libbe ? +> +> Using libbe directly is easier, but also more tightly tied to the be +> internals which could weigh down future refactoring. Partly I'm +> afraid of our 2.5 different html-output mechanisms. Either their +> should be a single Right Way that tries to satisfy everyone, or a +> smorgasbord of loosely coupled translators, so it's not so painful to +> kill them if/when they go out of style :p. + +I know that using libbe I am more tightly tied to the internals, but +I am trying to keep the command code and the presentation code crearly +separated to minimize this problem. I am not sure this is a real problem +anyway. + + +> On Mon, Jul 06, 2009 at 10:46:54PM +0200, Gianluca Montecchi wrote: +>> On Saturday 04 July 2009 02:31:26 Chris Ball wrote: +>> > It might be a good idea for "be html" to use the CherryPy web +>> interface +>> > that Steve is working on. The command could start up the CherryPy app +>> > and scrape all of the available pages to get a stand-alone dump; this +>> > would avoid having to keep two (okay, more than two at this point) +>> > separate sets of HTML templates in the source tree. What do you +>> think? +>> +>> It can be do, but this implies that CherryPy must be installed and +>> configured, +>> a thing that I don't want to impose. My idea is to offer a simpler way +>> to have +>> some html pages, where you just need to have BE installed. +> +> I agree that not needing CherryPy for a static html dump is good. +> Also, read-only templates will look different from the CherryPy +> interactive templates. +1 for another quasi-redundant template set +> ;). + +The look is not a problem. I can always use the same html Steve is using. +I am also playing with the idea to have the template themeable some time +after I have a fully working version. + +> +>> > > 2) I see that every command is implemented with a python file in +>> > > the becommand dir. For a better code, I'd like to split the +>> > > command implementation into two files: a file that contain the +>> > > actual code and a second file that have the html related part, +>> > > any problem with this ? I don't like to have the html part and +>> > > the code part in one big and unreadable file. +>> > +>> > I agree that becommands/*.py commands should not contain any HTML +>> > layout code. Putting it somewhere else instead sounds fine. +>> +>> I am in doubt with the "somewhere else", since for now I put the html +>> template +>> into a separate file in the same directory. Suggestion ? +> +> I think that only code intended only for command line use only should +> go into becommands, but really, just dump it anywhere and we can shift +> it around later :p. + +Of course. + +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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/values new file mode 100644 index 0000000..e846ff5 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/values @@ -0,0 +1,14 @@ +Alt-id: <6f719a1c43fdcba8bdbfee1130072595.squirrel@webmail.grys.it> + + +Content-type: text/plain + + +Date: Tue, 07 Jul 2009 14:15:08 +0200 + + +From: gian@grys.it + + +In-reply-to: 83202b83-eea8-452f-8239-d468940bddba + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/body new file mode 100644 index 0000000..d8f14fc --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/body @@ -0,0 +1,32 @@ +Hello to everyone + +As i said in a previous mail, I am working on a "html" command for be. +The goal is to be able to do something like "be html /web/page" to have in the +/web/page directory some static html pages that basically are the dump of the +be repository, much like ditz have +This will enable a simple and fast publish of the bus list and details on the +web, at least in read only mode. + +So I'd like to ask some question: +1) is it ok to develop this command ? I know that this is not a fully featured +web interface, but I am sure that it can be usefull. + +I am open to suggestion about it of course. + +2) I see that every command is implemented with a python file in the becommand +dir. For a better code, I'd like to split the command implementation into two +files: a file that contain the actual code and a second file that have the html +related part, any problem with this ? I don't like to have the html part and +the code part in one big and unreadable file. + +I'd like to hear other opinion about this. + +Thanks for now +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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/values new file mode 100644 index 0000000..e95ab61 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/values @@ -0,0 +1,11 @@ +Alt-id: <200907032250.17327.gian@grys.it> + + +Content-type: text/plain + + +Date: Fri, 03 Jul 2009 22:50:17 +0200 + + +From: Gianluca Montecchi <gian@grys.it> + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/body new file mode 100644 index 0000000..27dca1e --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/body @@ -0,0 +1,45 @@ +On Saturday 04 July 2009 02:31:26 Chris Ball wrote: +> Hi Gianluca, +> +> > As i said in a previous mail, I am working on a "html" command +> > for be. The goal is to be able to do something like "be html +> > /web/page" to have in the /web/page directory some static html +> > pages that basically are the dump of the be repository, much like +> > ditz have. This will enable a simple and fast publish of the bus +> > list and details on the web, at least in read only mode. +> +> It might be a good idea for "be html" to use the CherryPy web interface +> that Steve is working on. The command could start up the CherryPy app +> and scrape all of the available pages to get a stand-alone dump; this +> would avoid having to keep two (okay, more than two at this point) +> separate sets of HTML templates in the source tree. What do you think? + +It can be do, but this implies that CherryPy must be installed and configured, +a thing that I don't want to impose. My idea is to offer a simpler way to have +some html pages, where you just need to have BE installed. + +My very first implementation was a script that parse directly the .be directory +to build the pages, without BE itself installed. + + +> > 2) I see that every command is implemented with a python file in +> > the becommand dir. For a better code, I'd like to split the +> > command implementation into two files: a file that contain the +> > actual code and a second file that have the html related part, +> > any problem with this ? I don't like to have the html part and +> > the code part in one big and unreadable file. +> +> I agree that becommands/*.py commands should not contain any HTML +> layout code. Putting it somewhere else instead sounds fine. + +I am in doubt with the "somewhere else", since for now I put the html template +into a separate file in the same directory. Suggestion ? + +thanks +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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/values new file mode 100644 index 0000000..1bf2dc4 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/values @@ -0,0 +1,14 @@ +Alt-id: <200907062246.54804.gian@grys.it> + + +Content-type: text/plain + + +Date: Mon, 06 Jul 2009 22:46:54 +0200 + + +From: Gianluca Montecchi <gian@grys.it> + + +In-reply-to: b900f7fd-bab6-48c4-922c-a051f933da58 + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/body new file mode 100644 index 0000000..1d2b619 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/body @@ -0,0 +1,43 @@ +On Thursday 25 June 2009 16:23:04 Steve Losh wrote: +> On Jun 25, 2009, at 10:02 AM, Chris Ball <cjb@laptop.org> wrote: +> >> Oh, and obviously there must still be bugs in BE. Please submit +> >> more ;). +> > +> > Perhaps it's a good time to merge Steve Losh's CherryPy web interface? +> > +> > http://void.printf.net/pipermail/be-devel/2009-February/000095.html +> > http://bitbucket.org/sjl/cherryflavoredbugseverywhere/ +> +> Hey, I haven't touched the web interface in a while, but I should have +> some time to fix some stuff up tonight and tomorrow. Hold off on +> merging it in until then. +> +> I'm still curious as to what people think the role of a web interface +> like this should be. When I wrote it I meant it as a single-user +> interface like the command line one. It could definitely work as a +> public, read-only interface too. + +I'd really like to have some sort of web interface for BE, also in read-only +mode. + +I am thinking to write (actually I wrote some test code) a tool to parse a BE +repository to output a set of static html pages to put online, like the "ditz +html" command, but this was before I start to play with BE sourcecode, so now +I ma thinking to implement it as a BE command. + +> If the goal is to allow more than one person to add issues, how should +> commits go? One commit per change? Commit every X minutes if necessary? + +I think that a simple web interface should be read-only. + +Eventually, to allow to add issues also from the web interface, it should be +done to a specific branch, one commit per change. + +just my 2 cents... +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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/values new file mode 100644 index 0000000..2285e1d --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/values @@ -0,0 +1,11 @@ +Alt-id: <200906252203.08535.gian@grys.it> + + +Content-type: text/plain + + +Date: Thu, 25 Jun 2009 22:03:08 +0200 + + +From: Gianluca Montecchi <gian@grys.it> + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/body new file mode 100644 index 0000000..2e4f851 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/body @@ -0,0 +1,43 @@ +On Monday 06 July 2009 12:48:39 W. Trevor King wrote: +> On Mon, Jul 06, 2009 at 08:26:24AM +1000, Ben Finney wrote: +> > "W. Trevor King" <wking@drexel.edu> writes: +> > > On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote: +> > > > Instead of a separate command for each output format, could we have +> > > > a single "produce a static report of the bug database" command, and +> > > > specify output format as an option? +> > > +> > > Do people like this architecture better than my be-xml-to-mbox +> > > approach? +> > +> > I think this question is illuminated by the related question: Is mbox +> > output a static report, or another read-write data store? +> +> Gianluca is clearly thinking about a static report: + +You are right, static, but not exactly a report as I think Ben is thinking + +> +> On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote: +> > The goal is to be able to do something like "be html /web/page" to have +> > in the /web/page directory some static html pages that basically are the +> > dump of the be repository, much like ditz have +> +> I think truly interactive frontends like Steve's working on need to be +> build on top of libbe directly, since they'll need to make lots of +> small changes to the database, and it's to slow to be reloading the +> database for every change. Static dumps like my mbox or Gianluca's +> html could just parse the xml output of `be list' and other be +> commands. + +Ok, but if I want to have an html dump that is browseable, I need to parse the +xml. Am I correct ? +If yes, should not be easiear to use directly the libbe ? + + +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/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/values new file mode 100644 index 0000000..b61fc2b --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/values @@ -0,0 +1,14 @@ +Alt-id: <200907062238.56930.gian@grys.it> + + +Content-type: text/plain + + +Date: Mon, 06 Jul 2009 22:38:56 +0200 + + +From: Gianluca Montecchi <gian@grys.it> + + +In-reply-to: 55263144-9775-4b18-ab83-29d66ed91a53 + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/values new file mode 100644 index 0000000..093611e --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/values @@ -0,0 +1,20 @@ +assigned: Gianluca Montecchi <gian@grys.it> + + +creator: W. Trevor King <wking@drexel.edu> + + +reporter: Gianluca Montecchi <gian@grys.it> + + +severity: wishlist + + +status: assigned + + +summary: Static html report generation + + +time: Tue, 21 Jul 2009 18:43:06 +0000 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body new file mode 100644 index 0000000..fa9e963 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/body @@ -0,0 +1,36 @@ +* W. Trevor King (wking@drexel.edu) wrote: +> One problem is that we don't actually have "releases". People just +> clone a branch, install, and go. + + This is actually the main reason I've manually mirrored the tree in +the past, so that users of our projects can get BE. If tarballs were +available I probably wouldn't even bother, but bzr really isn't a nice +dependency for just submitting/commenting on bugs. + + Isn't there a bzr web interface that at least supports creating +tarballs/zips? It is pretty standard functionality for most other VCS' +web interfaces so I'm guessing there must be, but loggerhead seems not +to support it. + + If it is a case of not having the hardware to host a more featureful +web UI I may be able to offer some assistance. + +> If you're worried about stability, just clone from a more stable branch +> (i.e., Chris' trunk). I think > this is good for distributed development, +> but maybe makes it hard to package into a conventional release-based system. +> With the bzr patch number in setup.py as the patch release number, I would be +> releasing my 0.1.363 while Chris releases his 0.1.314, even though they're at +> about the same point. I would rather be releasing my +> 0.1.20090714121347 +> while Chris releases his +> 0.1.20090713154540 +> Since then the similarity is clearer. + + Both approaches seem pretty odd to me, as a user you would have no +idea if 0.1.200910302359 has the fixes you required in a release you +were using that was numbered 0.1.200907141554. Surely you'd at least be +{pre,suf}fixing a branch name to the version. + +Thanks, + +James diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values new file mode 100644 index 0000000..c064938 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/0c40c13a-3515-4b45-a8c3-142cceab9254/values @@ -0,0 +1,14 @@ +Alt-id: <20090714142942.GA5717@ukfsn.org> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 15:29:42 +0100 + + +From: James Rowe <jnrowe@gmail.com> + + +In-reply-to: ea01c122-e629-4d5c-afa7-b180f4a8748b + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body new file mode 100644 index 0000000..7e1434b --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/body @@ -0,0 +1,115 @@ +On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote: +> * W. Trevor King (wking@drexel.edu) wrote: +> > One problem is that we don't actually have "releases". People just +> > clone a branch, install, and go. +> +> This is actually the main reason I've manually mirrored the tree in +> the past, so that users of our projects can get BE. If tarballs were +> available I probably wouldn't even bother, but bzr really isn't a nice +> dependency for just submitting/commenting on bugs. + +Fair enough. It will be good when we get a commit-able web interface +and/or email interface going. + +> Isn't there a bzr web interface that at least supports creating +> tarballs/zips? It is pretty standard functionality for most other VCS' +> web interfaces so I'm guessing there must be, but loggerhead seems not +> to support it. + +Unfortunately, people would still need bzr to install the versioned source: + + libbe/_version.py: + bzr version-info --format python > $@ + +So you'll need a "release" target in the makefile to build a bzr-less +install. While you're at it, you should probably compile the manpage +too to remove the docbook-to-man dependency. + +Do people want a HEAD tarball too? There must be a bzr equivalent of + .git/hooks/post-update +but I don't know what it is. + +> > If you're worried about stability, just clone from a more stable branch +> > (i.e., Chris' trunk). I think > this is good for distributed development, +> > but maybe makes it hard to package into a conventional release-based system. +> > With the bzr patch number in setup.py as the patch release number, I would be +> > releasing my 0.1.363 while Chris releases his 0.1.314, even though they're at +> > about the same point. I would rather be releasing my +> > 0.1.20090714121347 +> > while Chris releases his +> > 0.1.20090713154540 +> > Since then the similarity is clearer. +> +> Both approaches seem pretty odd to me, as a user you would have no +> idea if 0.1.200910302359 has the fixes you required in a release you +> were using that was numbered 0.1.200907141554. Surely you'd at least be +> {pre,suf}fixing a branch name to the version. + +"be --version" currently gives you the revision id: + wking@drexel.edu-20090714121347-c6rloikst1t3m5yl +which tells you exactly which commit your installed version is based on. +If we want stick with revision numbers, how about: + major.minor.revno-branch_nick +But then we'd have to pick "unique" branch nicknames... + +I'd sliced out the timestamp portion of the revision id so that the +"patch-number" would be an integer and the branch name wasn't +references, so that "upgrading" from one branch to another could be +transparent to the users (who just see an increading timestamp), but +still available to the developers (who know when commits were made to +the branches they track, and the likelyhood of to-the-second commit +collisions in official packages is small). + +On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote: +> "W. Trevor King" <wking@drexel.edu> writes: +> +> > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote: +> > > Please, no. Timestamps aren't version strings, that's conflating two +> > > pieces of information with very different meanings. Correlating the +> > > two is the job of a changelog. +> > +> > Which we don't bother keeping (also NEWS), since "bzr log" works so +> > nicely. +> +> That's not a changelog, that's a commit log of every source-level commit +> made. Far too much detail for a changelog of *user-visible* changes +> associated with a release. + +I need a user around to help me determine "user-visable" changes ;). +My labmates loose interest after be init/new/comment :p. None of +which has ever changed, other than set-root -> init ;). + +> > The timestamp should at least replace the patch release number, which +> > you agree is-desirable-to increase motonically ;). +> +> I still disagree that a timestamp is the right thing to use there. If +> you want a monotonically-increasing indicator of which revision we're up +> to, that's immediately available with the revision number from VCS on +> the main branch. That also has the advantage of producing consecutive +> numbers for each revision, by definition. + +But not during branch-switches, while my method skips large regions, +but probably increases during any reasonable branch-switch. For +example, when I upgraded to rich root to pull Ben's patch, I'm not +sure if Chris upgraded the trunk and merged my branch, or just ditched +the trunk and cloned my branch. Using actual bzr revision numbers +would make switching branches that either wrong (in the case of +rev-id decreases) or confusing (in the case of a single +non-consecutive increase). + +On Tue, Jul 14, 2009 at 11:11:31AM -0400, Chris Ball wrote: +> > I agree that's a problem. I think the solution is to start making +> > releases, with specific version strings, as source tarballs. +> +> I'm happy to do this if people think it would be useful, and I don't +> yet have a strong opinion on whether the releases should come with +> version numbers or timestamps. + +I imagine the news from 2006 to now will be somewhat abridged ;). + +-- +This email may be signed or encrypted with GPG (http://www.gnupg.org). +The GPG signature (if present) will be attached as 'signature.asc'. +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values new file mode 100644 index 0000000..4538a9f --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/1f40efc1-6efc-4dd8-bdd2-97907e5aa624/values @@ -0,0 +1,14 @@ +Alt-id: <20090714171725.GB10445@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 13:17:25 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 0c40c13a-3515-4b45-a8c3-142cceab9254 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body new file mode 100644 index 0000000..a0b6a14 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body @@ -0,0 +1,58 @@ +Chris Ball <cjb@laptop.org> writes: + +> Hi, +> +> > That's not a changelog, that's a commit log of every source-level +> > commit made. Far too much detail for a changelog of +> > *user-visible* changes associated with a release. +> +> I think I agree with both of you. :) It seems like it's both true that +> there's no point in keeping a GNU-style ChangeLog these days + +I think I have a better understanding of why this apparent disagreement +occurred, and it was due to my sloppy use of terms. + +Looking into it further, it seems there is a certain expectation (set, +in part, by the long-standing GNU coding conventions) that a “GNU-style +ChangeLog” contains not only a particular *format*, but information at +a particular level of *detail*. + +That is, a GNU ChangeLog is intended for the style of work where one +logs all the changes made to every file in the tree each working day, +and then makes a new day's entry above that, and so on. This is, of +course, entirely redundant with a VCS revision history, which makes all +the commit messages available on request. + +So to disambiguate, that's not what I meant. I'm more familiar with a +less-frequently-updated and less-fine-detail change log; perhaps more +akin to the GNU-style “NEWS” file. + +> and that if we make a release we should write an announce mail that +> directly mentions new user-visible changes as well as attaching the +> commit log. That smaller list of highly user-visible changes could +> live in NEWS, or in the announce mail, or both. + +Yes, that's mostly what I meant. + +I actually don't think the commit log needs to be part of the release at +all. It's of interest only to those who want fine-level detail about +changes to every file, and for that purpose I think read access to the +VCS is much better. Packaging a static copy of the commit log as plain +text seems pointless. + +Rather, we should treat a user-changes level “NEWS” file (or whatever +name we choose for it) as part of the documentation, and set the +expectation among the team that it will be updated for each user-visible +change being worked on, like any other documentation. + +-- + \ “… Nature … is seen to do all things Herself and through | + `\ herself of own accord, rid of all gods.” —Titus Lucretius | +_o__) Carus, c. 40 BCE | +Ben Finney + + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values new file mode 100644 index 0000000..4e3ade1 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/values @@ -0,0 +1,14 @@ +Alt-id: <87hbxdhtkp.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Thu, 16 Jul 2009 19:21:10 +1000 + + +From: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body new file mode 100644 index 0000000..5f478b5 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/body @@ -0,0 +1,96 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +W. Trevor King wrote: +> Thinking about this some more, I think that the role of the +> main-branch is to officially sanction the current state of the code as +> "released". If a series of commits will leave a branch in a +> known-unusable form, they should be carried out in some appropriately +> named development branch. Then the log of commits to the main branch +> ("bzr log -n 1" for bzr > ) should produce a fairly respectable +> changelog. + +This is how we develop bzr itself. The mainline is controlled by PQM, +which is a tool that merges feature branches, runs the tests, and +commits only if the tests pass. + +$ bzr log --short --limit 10 + 4534 Canonical.com Patch Queue Manager 2009-07-14 [merge] + (abentley) Implement merge --interactive + + 4533 Canonical.com Patch Queue Manager 2009-07-14 [merge] + (jml) Merge in changes from 1.17 branch. + + 4532 Canonical.com Patch Queue Manager 2009-07-14 [merge] + (igc) zc.buildout Windows build support (Sidnei da Silva) + + 4531 Canonical.com Patch Queue Manager 2009-07-13 [merge] + (vila) Delete forgotten debug print + + 4530 Canonical.com Patch Queue Manager 2009-07-13 [merge] + (vila) Isolate some tests from TZ + + 4529 Canonical.com Patch Queue Manager 2009-07-13 [merge] + (igc) Bazaar 2.0 Upgrade Guide + + 4528 Canonical.com Patch Queue Manager 2009-07-13 [merge] + (mbp) correction to news + + 4527 Canonical.com Patch Queue Manager 2009-07-13 [merge] + (jml) Merge in 1.17 branch, updating version numbers and NEWS file. + + 4526 Canonical.com Patch Queue Manager 2009-07-10 [merge] + (mbp, vila) Finish the *_implementation to per_* test renaming + + 4525 Canonical.com Patch Queue Manager 2009-07-10 [merge] + (vila) Quicker check for changes in mutable trees + +You can also see all the merges as they come into the mainline: + +$ bzr log --short --limit 10 --include-merges + 4534 Canonical.com Patch Queue Manager 2009-07-14 [merge] + (abentley) Implement merge --interactive + + 4526.6.15 Aaron Bentley 2009-07-14 + Update command help + + 4526.6.14 Aaron Bentley 2009-07-14 + Use default DiffWriter. + + 4526.6.13 Aaron Bentley 2009-07-14 + Add docstring to do_interactive. + + 4526.6.12 Aaron Bentley 2009-07-14 + Updates from review. + + 4526.6.11 Aaron Bentley 2009-07-13 + Update NEWS. + + 4526.6.10 Aaron Bentley 2009-07-13 [merge] + Merged apply-vocab into merge-interactive. + + 4526.7.4 Aaron Bentley 2009-07-13 [merge] + Merged bzr.dev into apply-vocab. + + 4526.6.9 Aaron Bentley 2009-07-13 [merge] + Merged apply-vocab into merge-interactive. + + 4526.7.3 Aaron Bentley 2009-07-13 + Test shelve_change. + +> This also means that _every_commit_ to a main branch would +> be an official release. + +We don't do that. We have official releases every 4 weeks, but we do +believe that running bzr.dev is pretty safe, because it's always tested +and our test suite is quite thorough. + +Aaron +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.9 (GNU/Linux) +Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org + +iEYEARECAAYFAkpcznIACgkQ0F+nu1YWqI0yhACePTFUUp6u+Dw+8IRwWOWBQRtb +TgsAniJq4lqnDfjNACMr7IEt7xYJhx7m +=BbGG +-----END PGP SIGNATURE----- diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values new file mode 100644 index 0000000..5134cf2 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2c95ee07-462d-42cf-8dc3-8f5389a392cb/values @@ -0,0 +1,14 @@ +Alt-id: <4A5CCE76.9040106@aaronbentley.com> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 14:29:10 -0400 + + +From: Aaron Bentley <aaron@aaronbentley.com> + + +In-reply-to: ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body new file mode 100644 index 0000000..b34e037 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body @@ -0,0 +1,52 @@ +On Tue, Jul 14, 2009 at 07:34:04PM +0100, jnrowe@gmail.com wrote: +> [This time to the list] +> +> * W. Trevor King (wking@drexel.edu) wrote: +> > On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote: +> > > Isn't there a bzr web interface that at least supports creating +> > > tarballs/zips? It is pretty standard functionality for most other VCS' +> > > web interfaces so I'm guessing there must be, but loggerhead seems not +> > > to support it. +> > +> > Unfortunately, people would still need bzr to install the versioned source: +> > +> > libbe/_version.py: +> > bzr version-info --format python > $@ +> +> I hadn't even seen that change go in. The last upstream change in the +> version I have installed locally was by you on 2008-11-24. + +It's only been in Chris' http://bzr.bugseverywhere.org/be/ branch +since revno: 321, 2009-06-25. Obviously we may have to adjust the +--verison output once we settle on a versioning scheme, but whatever +we pick, I think having the auto-generated libbe/_version.py around +for pinpointing bugs is worth the trouble of requiring bzr when +building distribution tarballs. + +> > So you'll need a "release" target in the makefile to build a bzr-less +> > install. While you're at it, you should probably compile the manpage +> > too to remove the docbook-to-man dependency. +> +> Maybe for others. Our packages just don't have the manpage as it is only +> the "be help" text reformatted, the easy option is sometimes the right +> one :) Also, I've just noticed that it has even less documentation in +> the bzr tree[1] making its installation much less compelling unless your +> packaging rules require a man page like Debians. +> +> Out of curiosity why is the Makefile being used for this stuff anyway? +> It is going to make it difficult to build locally when we finally get +> around to merging. Examples: If distutils was being used exclusively it +> would fix the #! lines in xml/*. We'd be able to point Python +> $version_of_the_day at setup.py instead of having to sed the Makefile or +> run setup and manually install other files. + +I speak Makefile better than I speak distutils ;). I'm not sure how +to translate the be.1 generation/installation or the libbe/_version.py +generation into distutils. Anyone else? + +-- +This email may be signed or encrypted with GPG (http://www.gnupg.org). +The GPG signature (if present) will be attached as 'signature.asc'. +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values new file mode 100644 index 0000000..0c1e529 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/values @@ -0,0 +1,14 @@ +Alt-id: <20090714191145.GB10606@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 15:11:45 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 6e315abe-a080-4369-8729-4aea2dee8494 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body new file mode 100644 index 0000000..7ffe231 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/body @@ -0,0 +1,38 @@ +[This time to the list] + +* W. Trevor King (wking@drexel.edu) wrote: +> On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote: +> > Isn't there a bzr web interface that at least supports creating +> > tarballs/zips? It is pretty standard functionality for most other VCS' +> > web interfaces so I'm guessing there must be, but loggerhead seems not +> > to support it. +> +> Unfortunately, people would still need bzr to install the versioned source: +> +> libbe/_version.py: +> bzr version-info --format python > $@ + + I hadn't even seen that change go in. The last upstream change in the +version I have installed locally was by you on 2008-11-24. + +> So you'll need a "release" target in the makefile to build a bzr-less +> install. While you're at it, you should probably compile the manpage +> too to remove the docbook-to-man dependency. + + Maybe for others. Our packages just don't have the manpage as it is only +the "be help" text reformatted, the easy option is sometimes the right +one :) Also, I've just noticed that it has even less documentation in +the bzr tree[1] making its installation much less compelling unless your +packaging rules require a man page like Debians. + + Out of curiosity why is the Makefile being used for this stuff anyway? +It is going to make it difficult to build locally when we finally get +around to merging. Examples: If distutils was being used exclusively it +would fix the #! lines in xml/*. We'd be able to point Python +$version_of_the_day at setup.py instead of having to sed the Makefile or +run setup and manually install other files. + +Thanks, + +James + 1. http://pullcord.laptop.org:4000/revision/314.1.15/doc/be.1.sgml diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values new file mode 100644 index 0000000..a4534a2 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/6e315abe-a080-4369-8729-4aea2dee8494/values @@ -0,0 +1,14 @@ +Alt-id: <20090714183404.GB26032@ukfsn.org> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 19:34:04 +0100 + + +From: jnrowe@gmail.com + + +In-reply-to: 1f40efc1-6efc-4dd8-bdd2-97907e5aa624 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body new file mode 100644 index 0000000..24ff7b0 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/body @@ -0,0 +1,58 @@ +"W. Trevor King" <wking@drexel.edu> writes: + +> Currently setup.py sets the version number for BE to 0.0.193 and the +> url to http://panoramicfeedback.com/opensource/. These are both a bit +> outdated ;). + +Right, that should change. + +> I've switched my branch over to the current url, and moved to +> last-commit-timestamp version numbers. + +Please, no. Timestamps aren't version strings, that's conflating two +pieces of information with very different meanings. Correlating the two +is the job of a changelog. + +> This removes the "prefered branch" issues with the old scheme, and +> version numbers should increase monotonically + +The English word “should” is ambiguous in this context. Are you saying +this is desirable, or are you predicting that it will likely be the +case? + +I don't see how it's either, so am doubly confused :-) + +> but it looses any stability information suggested by the preceding +> 0.0. + +The convention for three-part version strings is often: + + * Major release number (big changes in how the program works, + increasing monotonically per major release, with “0”indicating no + major release yet) + + * Minor release number (smaller impact on how the program works, + increasing monotonically per minor release, with “0” indicating no + minor release yet since the previous major) + + * Patch release number (bug-fix and other changes that don't affect + the documented interface, increasing monotonically per patch + release, with “0” indicating no patch release since the previous + major or minor) + +Obviously there's no standard or enforcement for this, but that's the +interpretation I usually give to dotted version strings in the absence +of more formal declaration specific to the project. + +> We can add those back in if people want. Does the first 0 mean +> "interfaces in flux" and the second 0 mean "lots of bugs"? If so, I +> think we're up to 0.1, since the major features are pretty calm. + +I disagree with your interpretation and prefer mine, above; on that +basis, I agree that we're at least up to version 0.1 by now :-) + +-- + \ “A lot of water has been passed under the bridge since this | + `\ variation has been played.” chess book, Russia | +_o__) | +Ben Finney diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values new file mode 100644 index 0000000..1b70837 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/744435b7-1521-4059-a55d-f0c403d7b4d8/values @@ -0,0 +1,14 @@ +Alt-id: <87ocrnjvat.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 22:36:26 +1000 + + +From: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body new file mode 100644 index 0000000..8b32751 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/body @@ -0,0 +1,14 @@ +Hi, + + > Which we don't bother keeping (also NEWS), since "bzr log" works + > so nicely. If you really want an standard changelog, see + > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00186.html + +Actually, there's a `bzr log --gnu-changelog` now, and `bzr help +log-formats` offers some more styles. (None of them seem to match +my preferred style for release announcements exactly, which would +be `git shortlog`-style.) + +- Chris. +-- +Chris Ball <cjb@laptop.org> diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values new file mode 100644 index 0000000..ea6e6aa --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a536cee5-cc8d-4b18-b491-657e0c7998b4/values @@ -0,0 +1,14 @@ +Alt-id: <m3ljmrfgot.fsf@pullcord.laptop.org> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 11:05:38 -0400 + + +From: Chris Ball <cjb@laptop.org> + + +In-reply-to: ea01c122-e629-4d5c-afa7-b180f4a8748b + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body new file mode 100644 index 0000000..33a8d66 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/body @@ -0,0 +1,51 @@ +I don't think anyone's changing their mind ;), so tallying the +comments so far: + +On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote: +> I still disagree that a timestamp is the right thing to use there. If +> you want a monotonically-increasing indicator of which revision we're up +> to, that's immediately available with the revision number from VCS on +> the main branch. That also has the advantage of producing consecutive +> numbers for each revision, by definition. + ++1 for trunk version number. + +On Tue, Jul 14, 2009 at 05:27:52PM +0200, Elena of Valhalla wrote: +> I also have a weak preference for version numbers, as long as they +> give useful informations on the state the release. + ++1 for trunk version number. + +On Tue, Jul 14, 2009 at 02:29:10PM -0400, Aaron Bentley wrote: +> We don't do that. We have official releases every 4 weeks, but we do +> believe that running bzr.dev is pretty safe, because it's always tested +> and our test suite is quite thorough. + ++1 for by hand version bumps. + +On Fri, Jul 17, 2009 at 11:37:49PM +0200, Gianluca Montecchi wrote: +> The version number of trunk _is_ should be the official version number of the +> Bugs Everywhere releases. +> The version number in branch does not means nothing outside the branch. +> At least we can have a mechanism to build a version number scheme that is +> consistent for us to be able to merge branch easily. + ++1 for trunk version number. + +And me with my timestamps ;). + +Sounds like we should go with trunk version number, but that it should +be set by hand whenever Chris decides to release something, since the +rest of us don't know what version the trunk is on. Unless we do +something like: + bzr log -n 0 | grep -B2 'nick: be$' | head -n1 | sed 's/ *revno: \([0-9]*\).*/\1/' +to extract the last trunk commit referenced from our branch. + +Implementation preferences? (i.e. Chris vs. regexp matching :p) + +-- +This email may be signed or encrypted with GPG (http://www.gnupg.org). +The GPG signature (if present) will be attached as 'signature.asc'. +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values new file mode 100644 index 0000000..1acfd91 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/a845096e-3cdf-41ed-a0e3-283439665b92/values @@ -0,0 +1,14 @@ +Alt-id: <20090718105008.GA31639@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Sat, 18 Jul 2009 06:50:08 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: c35835c0-8f9f-4090-ba92-1f616867e486 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body new file mode 100644 index 0000000..063afcb --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body @@ -0,0 +1,30 @@ +Hi, + + > That's not a changelog, that's a commit log of every source-level + > commit made. Far too much detail for a changelog of + > *user-visible* changes associated with a release. + +I think I agree with both of you. :) It seems like it's both true that +there's no point in keeping a GNU-style ChangeLog these days, and that +if we make a release we should write an announce mail that directly +mentions new user-visible changes as well as attaching the commit log. +That smaller list of highly user-visible changes could live in NEWS, +or in the announce mail, or both. + + > I agree that's a problem. I think the solution is to start making + > releases, with specific version strings, as source tarballs. + +I'm happy to do this if people think it would be useful, and I don't +yet have a strong opinion on whether the releases should come with +version numbers or timestamps. + +Thanks, + +- Chris. +-- +Chris Ball <cjb@laptop.org> + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values new file mode 100644 index 0000000..761c219 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/values @@ -0,0 +1,14 @@ +Alt-id: <m3k52bfgf0.fsf@pullcord.laptop.org> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 11:11:31 -0400 + + +From: Chris Ball <cjb@laptop.org> + + +In-reply-to: ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body new file mode 100644 index 0000000..1e2a870 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/body @@ -0,0 +1,37 @@ +On Tue, Jul 14, 2009 at 01:17:25PM -0400, W. Trevor King wrote: +> On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote: +> > "W. Trevor King" <wking@drexel.edu> writes: +> > +> > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote: +> > > > Please, no. Timestamps aren't version strings, that's conflating two +> > > > pieces of information with very different meanings. Correlating the +> > > > two is the job of a changelog. +> > > +> > > Which we don't bother keeping (also NEWS), since "bzr log" works so +> > > nicely. +> > +> > That's not a changelog, that's a commit log of every source-level commit +> > made. Far too much detail for a changelog of *user-visible* changes +> > associated with a release. +> +> I need a user around to help me determine "user-visable" changes ;). +> My labmates loose interest after be init/new/comment :p. None of +> which has ever changed, other than set-root -> init ;). + +Thinking about this some more, I think that the role of the +main-branch is to officially sanction the current state of the code as +"released". If a series of commits will leave a branch in a +known-unusable form, they should be carried out in some appropriately +named development branch. Then the log of commits to the main branch +("bzr log -n 1" for bzr > ) should produce a fairly respectable +changelog. Obviously we are all quite guilty of doing most of our +development in single branches, but it may be a useful model going +forward. This also means that _every_commit_ to a main branch would +be an official release. + +-- +This email may be signed or encrypted with GPG (http://www.gnupg.org). +The GPG signature (if present) will be attached as 'signature.asc'. +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values new file mode 100644 index 0000000..4439bad --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ae4f8f1e-6f86-4f81-ba9f-4042deb2ee68/values @@ -0,0 +1,14 @@ +Alt-id: <20090714182034.GA10606@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 14:20:34 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 1f40efc1-6efc-4dd8-bdd2-97907e5aa624 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body new file mode 100644 index 0000000..e02bd38 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/body @@ -0,0 +1,25 @@ +On Tue, Jul 14, 2009 at 5:11 PM, Chris Ball<cjb@laptop.org> wrote: +> > I agree that's a problem. I think the solution is to start making +> > releases, with specific version strings, as source tarballs. +> +> I'm happy to do this if people think it would be useful, and I don't +> yet have a strong opinion on whether the releases should come with +> version numbers or timestamps. + +as an user of be that plans to try and "package" it for openembedded, +a release would be very useful: writing a recipe that downloads a +specific commit from bzr and builds it is probably feasible, but +definitely not ideal. + +I also have a weak preference for version numbers, as long as they +give useful informations on the state the release. + +-- +Elena ``of Valhalla'' + +email: elena.valhalla@gmail.com + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values new file mode 100644 index 0000000..5d49c42 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/b19a8f6a-1d7b-4887-a9df-123d59b0cd9b/values @@ -0,0 +1,14 @@ +Alt-id: <5c5e5c350907140827u218553e8rc5773325d43c2bf2@mail.gmail.com> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 17:27:52 +0200 + + +From: Elena of Valhalla <elena.valhalla@gmail.com> + + +In-reply-to: aad59898-8949-44fb-ad0b-2acea6eb2ef8 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body new file mode 100644 index 0000000..d8014d2 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body @@ -0,0 +1,102 @@ +On Thursday 16 July 2009 12:38:55 W. Trevor King wrote: +> On Thu, Jul 16, 2009 at 07:32:31PM +1000, Ben Finney wrote: +> > "W. Trevor King" <wking@drexel.edu> writes: +> > > On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote: +> > > > "W. Trevor King" <wking@drexel.edu> writes: +> > > > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote: +> > > > > > Please, no. Timestamps aren't version strings, that's conflating +> > > > > > two pieces of information with very different meanings. +> > > > > > Correlating the two is the job of a [NEWS file]. +> > > > +> > > > If you want a monotonically-increasing indicator of which revision +> > > > we're up to, that's immediately available with the revision number +> > > > from VCS on the main branch. That also has the advantage of +> > > > producing consecutive numbers for each revision, by definition. +> > > +> > > But not during branch-switches, while my method skips large regions, +> > > but probably increases during any reasonable branch-switch. +> > +> > I've read this several times now, and I don't see what it's saying. +> > +> > The assumption I'm making is that there is a single canonical “main +> > branch”, from which releases will be made. +> +> I don't think you need to assume this. See my "virtual branch" +> argument below. + +But if we have a canonical "main branch" that we release, and the packager +get, we can refer to it as the stable branch, that it is not a bad idea. + + + +> > The version number set in that branch is the one which determines +> > the version of Bugs Everywhere as a whole. +> +> If you are suggesting that the dev branches adjust their release +> number _by_hand_ to match the current trunk release number, that +> allows switching, but sounds like a lot of work and isn't correct +> anyway, since they are not in the same state as the trunk. + +The version number of trunk _is_ should be the official version number of the +Bugs Everywhere releases. +The version number in branch does not means nothing outside the branch. +At least we can have a mechanism to build a version number scheme that is +consistent for us to be able to merge branch easily. + +> > The revision number is only useful in the context of the branch, so it +> > only matters when comparing versions within a branch. When you switch +> > between branches, if you're interested in the revision number you'll +> > still need to know which branch you're talking about. +> +> I think this is our main disagreement. I see all the branches as part +> of the same codebase, with monotonically increasing timestamp patch +> numbers. If you were to collapse all the commit snapshots down into a +> single chronological "virtual branch", it would still make sense, it +> would just be a bit unorganized. We do all try to move in the same +> general direction ;). + +I don't think that, outside the developers, a version number like + +cjb@laptop.org-20090713154540-ve4pmydqzb1ghgvc + +is a good choice, not for the user of BE, not for the packager of BE + + +> > This, then, is an argument for not having the revision number in the +> > version string at all. The version then becomes a more traditional +> > “major.minor.patch” tuple, and is only ever updated when some release +> > manager of the canonical branch decides it's correct to do so. +> +> It is an argument for not using the revision number. You can avoid +> revision numbers by using hand-coded patch numbers, or by using +> timestamps, which is what we're trying to decide on :p. + +We can use both. +During the development we can use version number like + +x.y.z.timestamp + +As we decide to release a stable version, the release manager set the version +number to a more traditional x.y.z format, and create a branch (stable branch) + +This way we have these advantages: + +1) an user have a simple version number to use for bug report/feature +request/help request + +2) a packager have an easy life to choose to package a stable or a trunk +version, knowing what are they doing + +bonus) we can maintain a stable and a developmente source tree/branch, where +in the development tree we can make also backward incompatible modification to +the source without making any damage to the users/packagers, while in the +stable branch we can make only bugfix/security fix or port from the devel branch +some interesting features as long as they don't break compatibility. + +bye +Gianluca + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values new file mode 100644 index 0000000..a828a3a --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/values @@ -0,0 +1,14 @@ +Alt-id: <200907172337.49779.gian@grys.it> + + +Content-type: text/plain + + +Date: Fri, 17 Jul 2009 23:37:49 +0200 + + +From: Gianluca Montecchi <gian@grys.it> + + +In-reply-to: f925e56f-26f9-4620-82fb-a0f160f27921 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body new file mode 100644 index 0000000..4e8445a --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/body @@ -0,0 +1,18 @@ +Currently setup.py sets the version number for BE to 0.0.193 and the +url to http://panoramicfeedback.com/opensource/. These are both a bit +outdated ;). I've switched my branch over to the current url, and +moved to last-commit-timestamp version numbers. This removes the +"prefered branch" issues with the old scheme, and version numbers +should increase monotonically, but it looses any stability information +suggested by the preceding 0.0. + +We can add those back in if people want. Does the first 0 mean +"interfaces in flux" and the second 0 mean "lots of bugs"? If so, I +think we're up to 0.1, since the major features are pretty calm. + +-- +This email may be signed or encrypted with GPG (http://www.gnupg.org). +The GPG signature (if present) will be attached as 'signature.asc'. +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values new file mode 100644 index 0000000..94bb94d --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c/values @@ -0,0 +1,11 @@ +Alt-id: <20090714110543.GB4855@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 07:05:43 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body new file mode 100644 index 0000000..fce4941 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body @@ -0,0 +1,72 @@ +On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote: +> "W. Trevor King" <wking@drexel.edu> writes: +> > I've switched my branch over to the current url, and moved to +> > last-commit-timestamp version numbers. +> +> Please, no. Timestamps aren't version strings, that's conflating two +> pieces of information with very different meanings. Correlating the two +> is the job of a changelog. + +Which we don't bother keeping (also NEWS), since "bzr log" works so nicely. +If you really want an standard changelog, see + http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00186.html + +> > This removes the "prefered branch" issues with the old scheme, and +> > version numbers should increase monotonically +> +> The English word “should” is ambiguous in this context. Are you saying +> this is desirable, or are you predicting that it will likely be the +> case? + +Both. + +> I don't see how it's either, so am doubly confused :-) + +The timestamp should at least replace the patch release number, which +you agree is-desirable-to increase motonically ;). I also predict +that it will increase monotonically for any given branch, since the +branch HEAD will have both the most recent commit and the highest +version number. The only problem I can think of is having your clock +_way_ off, and that is unlikely enough to ignore. If you hop between +branches, the timestamp is much more likely to increase going to the +more modern branch than the bzr revision number, which desynchronize +between branches fairly quickly. + +> The convention for three-part version strings is often: +> +> * Major release number (big changes in how the program works, +> increasing monotonically per major release, with “0”indicating no +> major release yet) +> +> * Minor release number (smaller impact on how the program works, +> increasing monotonically per minor release, with “0” indicating no +> minor release yet since the previous major) +> +> * Patch release number (bug-fix and other changes that don't affect +> the documented interface, increasing monotonically per patch +> release, with “0” indicating no patch release since the previous +> major or minor) + +One problem is that we don't actually have "releases". People just +clone a branch, install, and go. If you're worried about stability, +just clone from a more stable branch (i.e., Chris' trunk). I think +this is good for distributed development, but maybe makes it hard to +package into a conventional release-based system. With the bzr patch +number in setup.py as the patch release number, I would be releasing +my 0.1.363 while Chris releases his 0.1.314, even though they're at +about the same point. I would rather be releasing my + 0.1.20090714121347 +while Chris releases his + 0.1.20090713154540 +Since then the similarity is clearer. + +At any rate, I think the two approaches are close enough that an +auto-updating timestamp beats a manually bumped patch number, since +no-one ever actually bumps the patch number ;). + +-- +This email may be signed or encrypted with GPG (http://www.gnupg.org). +The GPG signature (if present) will be attached as 'signature.asc'. +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values new file mode 100644 index 0000000..c863757 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values @@ -0,0 +1,14 @@ +Alt-id: <20090714133732.GB6160@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Tue, 14 Jul 2009 09:37:32 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 744435b7-1521-4059-a55d-f0c403d7b4d8 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body new file mode 100644 index 0000000..5eeb353 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/body @@ -0,0 +1,88 @@ +On Thu, Jul 16, 2009 at 07:32:31PM +1000, Ben Finney wrote: +> "W. Trevor King" <wking@drexel.edu> writes: +> +> > On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote: +> > > "W. Trevor King" <wking@drexel.edu> writes: +> > > +> > > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote: +> > > > > Please, no. Timestamps aren't version strings, that's conflating +> > > > > two pieces of information with very different meanings. +> > > > > Correlating the two is the job of a [NEWS file]. +> > +> > > If you want a monotonically-increasing indicator of which revision +> > > we're up to, that's immediately available with the revision number +> > > from VCS on the main branch. That also has the advantage of +> > > producing consecutive numbers for each revision, by definition. +> > +> > But not during branch-switches, while my method skips large regions, +> > but probably increases during any reasonable branch-switch. +> +> I've read this several times now, and I don't see what it's saying. +> +> The assumption I'm making is that there is a single canonical “main +> branch”, from which releases will be made. + +I don't think you need to assume this. See my "virtual branch" +argument below. + +> The version number set in that branch is the one which determines +> the version of Bugs Everywhere as a whole. + +If you are suggesting that the dev branches adjust their release +number _by_hand_ to match the current trunk release number, that +allows switching, but sounds like a lot of work and isn't correct +anyway, since they are not in the same state as the trunk. + +> The revision number is only useful in the context of the branch, so it +> only matters when comparing versions within a branch. When you switch +> between branches, if you're interested in the revision number you'll +> still need to know which branch you're talking about. + +I think this is our main disagreement. I see all the branches as part +of the same codebase, with monotonically increasing timestamp patch +numbers. If you were to collapse all the commit snapshots down into a +single chronological "virtual branch", it would still make sense, it +would just be a bit unorganized. We do all try to move in the same +general direction ;). + +> Switching between branches doesn't change the canonical version string. + +Different released code should have different version numbers. + +> > For example, when I upgraded to rich root to pull Ben's patch, I'm not +> > sure if Chris upgraded the trunk and merged my branch, or just ditched +> > the trunk and cloned my branch. Using actual bzr revision numbers +> > would make switching branches that either wrong (in the case of rev-id +> > decreases) or confusing (in the case of a single non-consecutive +> > increase). +> +> This, then, is an argument for not having the revision number in the +> version string at all. The version then becomes a more traditional +> “major.minor.patch” tuple, and is only ever updated when some release +> manager of the canonical branch decides it's correct to do so. + +It is an argument for not using the revision number. You can avoid +revision numbers by using hand-coded patch numbers, or by using +timestamps, which is what we're trying to decide on :p. + +> If we use the ‘bzr version-info --format=python > foo_version.py’ +> command in some build routine, the branch's revision number will be +> available directly within Python by importing that module. That would +> allow it to be output in some UI, if that's what you're interested in +> seeing. + +True. Which means that whichever version string wins out, the other +side will still be able to access the info we both want included ;). +We can certainly suggest that bug reporters submit their + be --verbose-version +when they submit bugs. The only role of the official "version string" +is to make life easy for packagers. If they woln't be switching +branches, then either of our proposals are fine. If they will, then +I think timestamps work better. + +-- +This email may be signed or encrypted with GPG (http://www.gnupg.org). +The GPG signature (if present) will be attached as 'signature.asc'. +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values new file mode 100644 index 0000000..36f4007 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/f925e56f-26f9-4620-82fb-a0f160f27921/values @@ -0,0 +1,14 @@ +Alt-id: <20090716103855.GA8579@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Thu, 16 Jul 2009 06:38:55 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: fdb615a4-168a-467b-8090-875c998455e5 + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body new file mode 100644 index 0000000..b36292a --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/body @@ -0,0 +1,55 @@ +"W. Trevor King" <wking@drexel.edu> writes: + +> On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote: +> > "W. Trevor King" <wking@drexel.edu> writes: +> > +> > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote: +> > > > Please, no. Timestamps aren't version strings, that's conflating +> > > > two pieces of information with very different meanings. +> > > > Correlating the two is the job of a [NEWS file]. +> +> > If you want a monotonically-increasing indicator of which revision +> > we're up to, that's immediately available with the revision number +> > from VCS on the main branch. That also has the advantage of +> > producing consecutive numbers for each revision, by definition. +> +> But not during branch-switches, while my method skips large regions, +> but probably increases during any reasonable branch-switch. + +I've read this several times now, and I don't see what it's saying. + +The assumption I'm making is that there is a single canonical “main +branch”, from which releases will be made. The version number set in +that branch is the one which determines the version of Bugs Everywhere +as a whole. + +The revision number is only useful in the context of the branch, so it +only matters when comparing versions within a branch. When you switch +between branches, if you're interested in the revision number you'll +still need to know which branch you're talking about. + +Switching between branches doesn't change the canonical version string. + +> For example, when I upgraded to rich root to pull Ben's patch, I'm not +> sure if Chris upgraded the trunk and merged my branch, or just ditched +> the trunk and cloned my branch. Using actual bzr revision numbers +> would make switching branches that either wrong (in the case of rev-id +> decreases) or confusing (in the case of a single non-consecutive +> increase). + +This, then, is an argument for not having the revision number in the +version string at all. The version then becomes a more traditional +“major.minor.patch” tuple, and is only ever updated when some release +manager of the canonical branch decides it's correct to do so. + +If we use the ‘bzr version-info --format=python > foo_version.py’ +command in some build routine, the branch's revision number will be +available directly within Python by importing that module. That would +allow it to be output in some UI, if that's what you're interested in +seeing. + +-- + \ “Never do anything against conscience even if the state demands | + `\ it.” —Albert Einstein | +_o__) | +Ben Finney diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values new file mode 100644 index 0000000..d373a73 --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/fdb615a4-168a-467b-8090-875c998455e5/values @@ -0,0 +1,14 @@ +Alt-id: <87d481ht1s.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Thu, 16 Jul 2009 19:32:31 +1000 + + +From: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body new file mode 100644 index 0000000..30e3cbd --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/body @@ -0,0 +1,44 @@ +"W. Trevor King" <wking@drexel.edu> writes: + +> On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote: +> > Please, no. Timestamps aren't version strings, that's conflating two +> > pieces of information with very different meanings. Correlating the +> > two is the job of a changelog. +> +> Which we don't bother keeping (also NEWS), since "bzr log" works so +> nicely. + +That's not a changelog, that's a commit log of every source-level commit +made. Far too much detail for a changelog of *user-visible* changes +associated with a release. + +> The timestamp should at least replace the patch release number, which +> you agree is-desirable-to increase motonically ;). + +I still disagree that a timestamp is the right thing to use there. If +you want a monotonically-increasing indicator of which revision we're up +to, that's immediately available with the revision number from VCS on +the main branch. That also has the advantage of producing consecutive +numbers for each revision, by definition. + +> One problem is that we don't actually have "releases". People just +> clone a branch, install, and go. + +I agree that's a problem. I think the solution is to start making +releases, with specific version strings, as source tarballs. + +James Rowe <jnrowe@gmail.com> writes: + +> Isn't there a bzr web interface that at least supports creating +> tarballs/zips? + +Even better: ‘bzr export /tmp/foo.tar.gz’ will create a source tarball +of all the files in the branch's VCS inventory. All we need to do is +start the practice of tagging a release in the VCS, and export the +tarball at that time. + +-- + \ “Pinky, are you pondering what I'm pondering?” “Well, I think | + `\ so (hiccup), but Kevin Costner with an English accent?” —_Pinky | +_o__) and The Brain_ | +Ben Finney diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values new file mode 100644 index 0000000..aa9b55f --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ffbf5ac9-e2f5-47ab-9c3c-33989c81ad42/values @@ -0,0 +1,14 @@ +Alt-id: <87k52bjoxe.fsf_-_@benfinney.id.au> + + +Content-type: text/plain + + +Date: Wed, 15 Jul 2009 00:54:05 +1000 + + +From: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +In-reply-to: cdf15bdd-d3fe-4251-9d0b-f1b687e9a26c + diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/values new file mode 100644 index 0000000..b9e8dff --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/values @@ -0,0 +1,17 @@ +creator: W. Trevor King <wking@drexel.edu> + + +reporter: W. Trevor King <wking@drexel.edu> + + +severity: wishlist + + +status: open + + +summary: How should we version BE? + + +time: Tue, 21 Jul 2009 17:19:22 +0000 + diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/00c6f4d8-f965-4d2f-a652-17e58c20ab8c/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/00c6f4d8-f965-4d2f-a652-17e58c20ab8c/body new file mode 100644 index 0000000..63b61ad --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/00c6f4d8-f965-4d2f-a652-17e58c20ab8c/body @@ -0,0 +1,26 @@ +Hi, + + > http://bitbucket.org/sjl/cherryflavoredbugseverywhere/ + +Cool! I've set up a copy here: + + http://bugsweb.bugseverywhere.org/ + +(Since we don't have any open bugs lately, click "Closed" at the top, +or create some, but don't expect them to persist if you do.) + + > anyone has any feedback (on any aspect of it) I'd appreciate it. + +I'm pretty enthusiastic about merging this and then working on it +further. + +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/d9959864-ea91-475a-a075-f39aa6760f98/comments/00c6f4d8-f965-4d2f-a652-17e58c20ab8c/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/00c6f4d8-f965-4d2f-a652-17e58c20ab8c/values new file mode 100644 index 0000000..f303bf3 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/00c6f4d8-f965-4d2f-a652-17e58c20ab8c/values @@ -0,0 +1,14 @@ +Alt-id: <m3eisxtgfx.fsf@pullcord.laptop.org> + + +Content-type: text/plain + + +Date: Fri, 03 Jul 2009 20:55:30 -0400 + + +From: Chris Ball <cjb@laptop.org> + + +In-reply-to: 2496ccca-130b-4459-bfae-9d9ef0138177 + diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/16357f68-19c0-4bf9-8220-b88b52b3456d/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/16357f68-19c0-4bf9-8220-b88b52b3456d/body new file mode 100644 index 0000000..3a08d71 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/16357f68-19c0-4bf9-8220-b88b52b3456d/body @@ -0,0 +1,35 @@ +Hi everyone. I found Bugs Everywhere and really like the idea of +distributed bug tracking. I felt like practicing building a CherryPy +site so I put together a quick web interface to BE. I know there's +already a TurboGears one in the works, but I needed an excuse to try +out CherryPy again after working with Django for a while. + +Would any of you be willing to take a look at what I've got so far and +tell me what you think I could improve? + +To install and use it: + +* Install CherryPy from http://cherrypy.org/ if you don't have it. +* Install Jinja2 from http://jinja.pocoo.org/2/ if you don't have it. +* Install BugsEverywhere - you probably know how to do this :) +* Download a zip/tar of my project (or hg clone) from http://bitbucket.org/sjl/cherryflavoredbugseverywhere/ +* Unzip my project and put the folder in your Python site-packages +directory. +* Symlink site-packages/cherryflavoredbugseverywhere/cfbe.py to /usr/ +local/bin/cfbe +* Use the "cfbe [project_root]" command to start up the web interface +for that project. +* Visit http://localhost:8080/ in a browser. + +I know that's a lot of steps. I'd like to streamline it quite a bit, +but first I wanted to see if you have any feedback on the system +itself. Thanks! + +-- +Steve Losh +http://stevelosh.com/ + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/16357f68-19c0-4bf9-8220-b88b52b3456d/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/16357f68-19c0-4bf9-8220-b88b52b3456d/values new file mode 100644 index 0000000..2029281 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/16357f68-19c0-4bf9-8220-b88b52b3456d/values @@ -0,0 +1,11 @@ +Alt-id: <272FECFE-D16B-47B7-B39A-E2C8A718CCC5@stevelosh.com> + + +Content-type: text/plain + + +Date: Sat, 07 Feb 2009 16:30:33 -0500 + + +From: Steve Losh <steve@stevelosh.com> + diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/body new file mode 100644 index 0000000..d2ef28c --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/body @@ -0,0 +1,77 @@ +Those are beautiful templates -- can you share those? I'd love to +study the HTML and CSS behind them. + +On Sat, Feb 7, 2009 at 5:48 PM, Steve Losh <steve@stevelosh.com> wrote: +> Hey Chris, thanks for the comments. +> +>> +>> My initial impression is that this looks good enough already to merge as +>> a replacement for the turbogears site. What does everyone else think? +>> +> +> I'm not quite sure it's there yet. There are a bunch of bugs I've got +> marked as "beta" that I'd like to see fixed before it's ready for real use. +> Hopefully they shouldn't be too tough to fix. You can point CFBE at itself +> to see them. :) +> +>> Could you explain a little about how you handle authorship of bug +>> changes at the moment, and if it looks plausible to try making it +>> multiuser? (Having it handle more than one "user" logged in at once.) +>> +> +> That's something I need advice on. Right now CFBE is pretty much only +> suitable for local use - you check out whatever you're working on and use it +> as a local interface to the bugs in the repository. Change those, check in, +> etc. It's effectively just a pretty version of the command line be tool. +> +> I haven't used CherryPy's session/authentication support before. This might +> be a good time for me to learn. One way it might be able to handle multiple +> users hitting a central server: +> +> * Each user has to register with the server and be approved by an admin. +> * Each account would be mapped to a contributor string, the same one that +> would show up if you were going to commit to the repository. +> * Once you have an account, you'd login to make any changes. +> +> +> Aside from all that, I'm a little fuzzy on how a centralized interface to a +> distributed bug tracking system should work. A read-only interface to a +> central "main" repository would be easy. Run the server in read-only mode +> pointing at the main repository. People can use it to look at the bugs in +> the tip of that repository. +> +> If it's not read-only, what happens when a user changes/adds/whatevers a +> bug? Should CFBE commit that change to the repository right then and there? +> Should it never commit, just update the bugdir and let the commits happen +> manually? +> +> What happens when you have multiple branches for a repository? Should there +> be one CFBE instance for each branch, or a single one that lets you switch +> between branches (effectively switching between revisions)? +> +> Those are the kind of things that don't really apply when CFBE is just a +> local interface to a single repository. If anyone has any advice on how a +> multi-user interface should work I'd love to hear it! +> +> -- +> Steve Losh +> http://stevelosh.com/ +> +> +> _______________________________________________ +> Be-devel mailing list +> Be-devel@bugseverywhere.org +> http://void.printf.net/cgi-bin/mailman/listinfo/be-devel +> + + + +-- +Matthew Wilson +matt@tplus1.com +http://tplus1.com + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/values new file mode 100644 index 0000000..96612e6 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/values @@ -0,0 +1,14 @@ +Alt-id: <f6f643a20902071531y6aa3d7a6k7c5a4bd4aa5a04f6@mail.gmail.com> + + +Content-type: text/plain + + +Date: Sat, 07 Feb 2009 18:31:04 -0500 + + +From: Matthew Wilson <matt@tplus1.com> + + +In-reply-to: 21c90231-d7f2-49bb-97d9-99e16459d799 + diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/21c90231-d7f2-49bb-97d9-99e16459d799/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/21c90231-d7f2-49bb-97d9-99e16459d799/body new file mode 100644 index 0000000..504f82b --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/21c90231-d7f2-49bb-97d9-99e16459d799/body @@ -0,0 +1,62 @@ +Hey Chris, thanks for the comments. + +> +> My initial impression is that this looks good enough already to +> merge as +> a replacement for the turbogears site. What does everyone else think? +> + +I'm not quite sure it's there yet. There are a bunch of bugs I've got +marked as "beta" that I'd like to see fixed before it's ready for real +use. Hopefully they shouldn't be too tough to fix. You can point +CFBE at itself to see them. :) + +> Could you explain a little about how you handle authorship of bug +> changes at the moment, and if it looks plausible to try making it +> multiuser? (Having it handle more than one "user" logged in at once.) +> + +That's something I need advice on. Right now CFBE is pretty much only +suitable for local use - you check out whatever you're working on and +use it as a local interface to the bugs in the repository. Change +those, check in, etc. It's effectively just a pretty version of the +command line be tool. + +I haven't used CherryPy's session/authentication support before. This +might be a good time for me to learn. One way it might be able to +handle multiple users hitting a central server: + +* Each user has to register with the server and be approved by an admin. +* Each account would be mapped to a contributor string, the same one +that would show up if you were going to commit to the repository. +* Once you have an account, you'd login to make any changes. + + +Aside from all that, I'm a little fuzzy on how a centralized interface +to a distributed bug tracking system should work. A read-only +interface to a central "main" repository would be easy. Run the +server in read-only mode pointing at the main repository. People can +use it to look at the bugs in the tip of that repository. + +If it's not read-only, what happens when a user changes/adds/whatevers +a bug? Should CFBE commit that change to the repository right then +and there? Should it never commit, just update the bugdir and let the +commits happen manually? + +What happens when you have multiple branches for a repository? Should +there be one CFBE instance for each branch, or a single one that lets +you switch between branches (effectively switching between revisions)? + +Those are the kind of things that don't really apply when CFBE is just +a local interface to a single repository. If anyone has any advice on +how a multi-user interface should work I'd love to hear it! + +-- +Steve Losh +http://stevelosh.com/ + + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/21c90231-d7f2-49bb-97d9-99e16459d799/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/21c90231-d7f2-49bb-97d9-99e16459d799/values new file mode 100644 index 0000000..7bdded2 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/21c90231-d7f2-49bb-97d9-99e16459d799/values @@ -0,0 +1,14 @@ +Alt-id: <D765386C-4D43-4AE0-83E3-986A1CB4008C@stevelosh.com> + + +Content-type: text/plain + + +Date: Sat, 07 Feb 2009 17:48:06 -0500 + + +From: Steve Losh <steve@stevelosh.com> + + +In-reply-to: 42d57a41-219f-46db-9fda-21b42351da63 + diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/2496ccca-130b-4459-bfae-9d9ef0138177/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/2496ccca-130b-4459-bfae-9d9ef0138177/body new file mode 100644 index 0000000..e160b76 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/2496ccca-130b-4459-bfae-9d9ef0138177/body @@ -0,0 +1,52 @@ +Speaking of that interface, I changed up the look and feel a bit last +weekend. It's still at http://bitbucket.org/sjl/cherryflavoredbugseverywhere/ + -- if anyone has any feedback (on any aspect of it) I'd appreciate it. + +-- +Steve + +On Jul 3, 2009, at 8:31 PM, Chris Ball wrote: + +> Hi Gianluca, +> +>> As i said in a previous mail, I am working on a "html" command +>> for be. The goal is to be able to do something like "be html +>> /web/page" to have in the /web/page directory some static html +>> pages that basically are the dump of the be repository, much like +>> ditz have. This will enable a simple and fast publish of the bus +>> list and details on the web, at least in read only mode. +> +> It might be a good idea for "be html" to use the CherryPy web +> interface +> that Steve is working on. The command could start up the CherryPy app +> and scrape all of the available pages to get a stand-alone dump; this +> would avoid having to keep two (okay, more than two at this point) +> separate sets of HTML templates in the source tree. What do you +> think? +> +>> 2) I see that every command is implemented with a python file in +>> the becommand dir. For a better code, I'd like to split the +>> command implementation into two files: a file that contain the +>> actual code and a second file that have the html related part, +>> any problem with this ? I don't like to have the html part and +>> the code part in one big and unreadable file. +> +> I agree that becommands/*.py commands should not contain any HTML +> layout code. Putting it somewhere else instead sounds fine. +> +> 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 + + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/2496ccca-130b-4459-bfae-9d9ef0138177/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/2496ccca-130b-4459-bfae-9d9ef0138177/values new file mode 100644 index 0000000..0c68560 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/2496ccca-130b-4459-bfae-9d9ef0138177/values @@ -0,0 +1,14 @@ +Alt-id: <4701D71B-A14D-4C63-ABCC-E7E5FFE4E4BA@stevelosh.com> + + +Content-type: text/plain + + +Date: Fri, 03 Jul 2009 20:34:51 -0400 + + +From: Steve Losh <steve@stevelosh.com> + + +In-reply-to: 16357f68-19c0-4bf9-8220-b88b52b3456d + diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/42d57a41-219f-46db-9fda-21b42351da63/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/42d57a41-219f-46db-9fda-21b42351da63/body new file mode 100644 index 0000000..f43e8dd --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/42d57a41-219f-46db-9fda-21b42351da63/body @@ -0,0 +1,32 @@ +Hi Steve, + + > Hi everyone. I found Bugs Everywhere and really like the idea of + > distributed bug tracking. I felt like practicing building a + > CherryPy site so I put together a quick web interface to BE. I + > know there's already a TurboGears one in the works, but I needed an + > excuse to try out CherryPy again after working with Django for a + > while. + +This looks awesome, thanks! I've taken some screenshots for others to +see: + +http://chris.printf.net/cfbe-main.png +http://chris.printf.net/cfbe-detail.png + +My initial impression is that this looks good enough already to merge as +a replacement for the turbogears site. What does everyone else think? + +Could you explain a little about how you handle authorship of bug +changes at the moment, and if it looks plausible to try making it +multiuser? (Having it handle more than one "user" logged in at once.) + +Great work, 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/d9959864-ea91-475a-a075-f39aa6760f98/comments/42d57a41-219f-46db-9fda-21b42351da63/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/42d57a41-219f-46db-9fda-21b42351da63/values new file mode 100644 index 0000000..7c7e41a --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/42d57a41-219f-46db-9fda-21b42351da63/values @@ -0,0 +1,14 @@ +Alt-id: <m3zlgxyjo5.fsf@pullcord.laptop.org> + + +Content-type: text/plain + + +Date: Sat, 07 Feb 2009 17:19:22 -0500 + + +From: Chris Ball <cjb@laptop.org> + + +In-reply-to: 16357f68-19c0-4bf9-8220-b88b52b3456d + diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/5e339bac-f4f3-407b-974a-b88795d3573b/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/5e339bac-f4f3-407b-974a-b88795d3573b/body new file mode 100644 index 0000000..7bea88c --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/5e339bac-f4f3-407b-974a-b88795d3573b/body @@ -0,0 +1,30 @@ +Hi, + + > Works for me. I've done this now, which closes the last open bug + > in my repo :D. + +Wow. Congrats! I've merged your branch. + + > All the new functionality comes from bug.extra_strings, which + > provides a list for storing arbitrary strings in the bug's + > permanent state. + +That's going to be really useful. + + > Next up: regexp searching for list --extra-strings! ;). + +Awesome. + + > Oh, and obviously there must still be bugs in BE. Please submit + > more ;). + +Perhaps it's a good time to merge Steve Losh's CherryPy web interface? + +http://void.printf.net/pipermail/be-devel/2009-February/000095.html +http://bitbucket.org/sjl/cherryflavoredbugseverywhere/ + +Thanks, + +- Chris. +-- +Chris Ball <cjb@laptop.org> diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/5e339bac-f4f3-407b-974a-b88795d3573b/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/5e339bac-f4f3-407b-974a-b88795d3573b/values new file mode 100644 index 0000000..9b607ef --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/5e339bac-f4f3-407b-974a-b88795d3573b/values @@ -0,0 +1,14 @@ +Alt-id: <m31vp82yyj.fsf@pullcord.laptop.org> + + +Content-type: text/plain + + +Date: Thu, 25 Jun 2009 10:02:44 -0400 + + +From: Chris Ball <cjb@laptop.org> + + +In-reply-to: 16357f68-19c0-4bf9-8220-b88b52b3456d + diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/7fa903a3-f9e6-4e4d-8128-0f26e1ce664b/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/7fa903a3-f9e6-4e4d-8128-0f26e1ce664b/body new file mode 100644 index 0000000..909b989 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/7fa903a3-f9e6-4e4d-8128-0f26e1ce664b/body @@ -0,0 +1,25 @@ +On Jun 25, 2009, at 10:02 AM, Chris Ball <cjb@laptop.org> wrote: +> +>> Oh, and obviously there must still be bugs in BE. Please submit +>> more ;). +> +> Perhaps it's a good time to merge Steve Losh's CherryPy web interface? +> +> http://void.printf.net/pipermail/be-devel/2009-February/000095.html +> http://bitbucket.org/sjl/cherryflavoredbugseverywhere/ +> + +Hey, I haven't touched the web interface in a while, but I should have +some time to fix some stuff up tonight and tomorrow. Hold off on +merging it in until then. + +I'm still curious as to what people think the role of a web interface +like this should be. When I wrote it I meant it as a single-user +interface like the command line one. It could definitely work as a +public, read-only interface too. + +If the goal is to allow more than one person to add issues, how should +commits go? One commit per change? Commit every X minutes if necessary? + +-- +Steve diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/7fa903a3-f9e6-4e4d-8128-0f26e1ce664b/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/7fa903a3-f9e6-4e4d-8128-0f26e1ce664b/values new file mode 100644 index 0000000..72597bc --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/7fa903a3-f9e6-4e4d-8128-0f26e1ce664b/values @@ -0,0 +1,14 @@ +Alt-id: <26FBD153-39C5-4641-AF5E-749731964086@stevelosh.com> + + +Content-type: text/plain + + +Date: Thu, 25 Jun 2009 10:23:04 -0400 + + +From: Steve Losh <steve@stevelosh.com> + + +In-reply-to: 5e339bac-f4f3-407b-974a-b88795d3573b + diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/e249e2aa-2029-4a96-bc84-962366e07fd6/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/e249e2aa-2029-4a96-bc84-962366e07fd6/body new file mode 100644 index 0000000..614abd3 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/e249e2aa-2029-4a96-bc84-962366e07fd6/body @@ -0,0 +1,33 @@ +On Sat, Feb 07, 2009 at 05:48:06PM -0500, Steve Losh wrote: +>> My initial impression is that this looks good enough already to merge as +>> a replacement for the turbogears site. What does everyone else think? +> +> I'm not quite sure it's there yet. There are a bunch of bugs I've +> got marked as "beta" that I'd like to see fixed before it's ready +> for real use. Hopefully they shouldn't be too tough to fix. You +> can point CFBE at itself to see them. :) + +Steve's also versioning it with Mercurial. Will he mind changing to +Bazaar? + +Steve, I've touched up CFBE to work with my current BE branch. Some +of the changes apply to the trunk BE, and hopefully the rest will +soon. I think the version-naming issue is what's currently blocking +their adoption ;). I've put up my CFBE branch at + static-http://www.physics.drexel.edu/~wking/code/hg/cfbe +for Mercurial. + +Everyone, should CFBE-specific discussions move off-list? More +generally, I've been sending in lots of what-I'm-working on messages, +but not hearing much back, so let me know if I'm being too obnoxious, +and I'll shut up (or at least move more off-list) ;). + +Cheers, +Trevor + +-- +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/d9959864-ea91-475a-a075-f39aa6760f98/comments/e249e2aa-2029-4a96-bc84-962366e07fd6/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/e249e2aa-2029-4a96-bc84-962366e07fd6/values new file mode 100644 index 0000000..37e1899 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/e249e2aa-2029-4a96-bc84-962366e07fd6/values @@ -0,0 +1,14 @@ +Alt-id: <20090721135907.GB4469@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Tue, 21 Jul 2009 09:59:07 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 21c90231-d7f2-49bb-97d9-99e16459d799 + diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/body b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/body new file mode 100644 index 0000000..ae6a5fe --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/body @@ -0,0 +1,69 @@ +On Thu, Jun 25, 2009 at 10:23:04AM -0400, Steve Losh wrote: +> I'm still curious as to what people think the role of a web interface like +> this should be. When I wrote it I meant it as a single-user interface like +> the command line one. It could definitely work as a public, read-only +> interface too. + +I think the multi-user/public is the way to go. I'd also like to see +a procmail-able script to handle multi-user/public access via email, +which would have all the same issues we're worrying about here. + +On Sat, Feb 07, 2009 at 05:48:06PM -0500, Steve Losh wrote: +> I haven't used CherryPy's session/authentication support before. This +> might be a good time for me to learn. One way it might be able to handle +> multiple users hitting a central server: +> +> * Each user has to register with the server and be approved by an admin. +> * Each account would be mapped to a contributor string, the same one that +> would show up if you were going to commit to the repository. +> * Once you have an account, you'd login to make any changes. + +This sounds good to me. Yay spam reduction ;). + +> If it's not read-only, what happens when a user changes/adds/whatevers a +> bug? Should CFBE commit that change to the repository right then and +> there? Should it never commit, just update the bugdir and let the commits +> happen manually? + +On Thu, Jun 25, 2009 at 10:23:04AM -0400, Steve Losh wrote: +> One commit per change? Commit every X minutes if necessary? + +On Sat, Feb 07, 2009 at 05:48:06PM -0500, Steve Losh wrote: +> What happens when you have multiple branches for a repository? Should +> there be one CFBE instance for each branch, or a single one that lets you +> switch between branches (effectively switching between revisions)? + +There are interesting discussions about the role of distributed +bugtracking here (I'm sure there are others): + http://lwn.net/Articles/281849/ + http://community.livejournal.com/evan_tech/248736.html + +Personally, I've never done much cherry-picking or anything that would +require me to determine exactly which parts of someone's work I want +and which I don't want. I just merge someone's head and edit out the +bits I don't like, a process that also works well for our current +"commit however you want" BE development model ;). Maybe that just +shows that I only work on minor branches of small projects :p. In the +absence of big-project advice, I think we just limit the web front end +to our current model, and let the web interface commit however it +wants as well ;). +1 for adding a <commit> button to the web +interface ;). + +One caveat about a multi-user interface would be that it would allow +the casual users to commit bugs about whatever version they had +installed onto the head of the public-bug branch. In order to figure +out what version of the project they were talking about, the project +should have a way for the user to get a unique version string, ideally +be the bzr-revision-id/git-commit/etc. of the commit for the version +they were using. This would allow developers to determine what branch +to work on with the bug fix, and what branches needed to pull the +eventual fix. If the initially reported buggy version wasn't actually +the root of the bug, oh well :p. Material for a later related bug +report or a reopen. + +-- +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/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/values new file mode 100644 index 0000000..2fa8470 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/fa60ce1f-a809-4fb3-a2cd-1a2e0bdd0e0a/values @@ -0,0 +1,14 @@ +Alt-id: <20090625154734.GA19441@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Thu, 25 Jun 2009 11:47:34 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 16357f68-19c0-4bf9-8220-b88b52b3456d + diff --git a/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/values b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/values new file mode 100644 index 0000000..8cf85c9 --- /dev/null +++ b/.be/bugs/d9959864-ea91-475a-a075-f39aa6760f98/values @@ -0,0 +1,20 @@ +assigned: Steve Losh <steve@stevelosh.com> + + +creator: W. Trevor King <wking@drexel.edu> + + +reporter: Steve Losh <steve@stevelosh.com> + + +severity: wishlist + + +status: assigned + + +summary: CherryPy interface "Cherry-flavored BE" + + +time: Tue, 21 Jul 2009 18:52:44 +0000 + diff --git a/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/09f950d4-9366-4e7b-98b3-9057999f8f38/body b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/09f950d4-9366-4e7b-98b3-9057999f8f38/body new file mode 100644 index 0000000..770af86 --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/09f950d4-9366-4e7b-98b3-9057999f8f38/body @@ -0,0 +1,19 @@ +On Thu, Jul 16, 2009 at 09:39:30AM -0400, W. Trevor King wrote: +> Disclaimer: I imaging the current implementation will choke on +> non-text/plain content types. Also possibly on non-ascii encodings. + +Non-ascii encodings are now handled (although now the output is +base64-encoded). This is limited by poor unicode handling in the +email module for current pythons, see the log for more details. + +> I should probably allow the "help" command ... ;). + +Added, but it currently shows _all_ commands, not just allowed +commands. + +-- +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/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/09f950d4-9366-4e7b-98b3-9057999f8f38/values b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/09f950d4-9366-4e7b-98b3-9057999f8f38/values new file mode 100644 index 0000000..d8edf61 --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/09f950d4-9366-4e7b-98b3-9057999f8f38/values @@ -0,0 +1,14 @@ +Alt-id: <20090718131220.GA31832@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Sat, 18 Jul 2009 09:12:20 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: f1cde826-0506-4b4a-92ab-8499e953fa49 + diff --git a/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/704b37ab-01bb-43d3-9e9f-f0d354f63c7d/body b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/704b37ab-01bb-43d3-9e9f-f0d354f63c7d/body new file mode 100644 index 0000000..e008923 --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/704b37ab-01bb-43d3-9e9f-f0d354f63c7d/body @@ -0,0 +1,27 @@ +On Sat, Jul 18, 2009 at 06:05:51PM -0400, W. Trevor King wrote: +> My email interface now supports bug creation/comments that look +> like: +> +> $ cat | mail -s "[be-bug] new" "whatever-dev@fancyprojects.com" +> The demuxulizer is broken +> +> <describe bug> +> ^D + +The move towards the DBT interface means this example should now look +like + + $ cat | mail -s "[be-bug:submit] The demuxulizer is broken" whatever-dev@fancyprojects.com + Version: XYZ + + <describe bug> + -- + Ignored text + ^D + +-- +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/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/704b37ab-01bb-43d3-9e9f-f0d354f63c7d/values b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/704b37ab-01bb-43d3-9e9f-f0d354f63c7d/values new file mode 100644 index 0000000..c00299a --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/704b37ab-01bb-43d3-9e9f-f0d354f63c7d/values @@ -0,0 +1,14 @@ +Alt-id: <20090719130649.GA4164@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Sun, 19 Jul 2009 09:06:49 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 7b904395-86e9-4eb1-8534-69cec63801d4 + diff --git a/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/7b904395-86e9-4eb1-8534-69cec63801d4/body b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/7b904395-86e9-4eb1-8534-69cec63801d4/body new file mode 100644 index 0000000..800609e --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/7b904395-86e9-4eb1-8534-69cec63801d4/body @@ -0,0 +1,27 @@ +Ah, it's been a good day :). My email interface now supports bug +creation/comments that look like: + + $ cat | mail -s "[be-bug] new" "whatever-dev@fancyprojects.com" + The demuxulizer is broken + + <describe bug> + ^D + +Which is probably easy enough for just about anybody ;). Also easy +for other projects to wrap into one of their tools: + + $ cat | projectAexecutable --report-bug + The demuxulizer is broken + + <describe bug> + ^D + +Which could do things like automatically add the version string, OS +name, etc. + +-- +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/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/7b904395-86e9-4eb1-8534-69cec63801d4/values b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/7b904395-86e9-4eb1-8534-69cec63801d4/values new file mode 100644 index 0000000..ab160fb --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/7b904395-86e9-4eb1-8534-69cec63801d4/values @@ -0,0 +1,14 @@ +Alt-id: <20090718220551.GB32230@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Sat, 18 Jul 2009 18:05:51 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: 09f950d4-9366-4e7b-98b3-9057999f8f38 + diff --git a/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/a0e846ed-1549-4ec3-b94d-391e54610f61/body b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/a0e846ed-1549-4ec3-b94d-391e54610f61/body new file mode 100644 index 0000000..087d67a --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/a0e846ed-1549-4ec3-b94d-391e54610f61/body @@ -0,0 +1,58 @@ +On Sun, Jul 19, 2009 at 09:09:05AM +1000, Ben Finney wrote: +> > The interface is basically "place your be command in the subject line" +> +> I would far prefer an interface of “place as many BE commands as you +> like at the top of the message body, ending with an optional terminator +> command, and they will each be executed in turn”. +> ... + +I think the idea behind my first approach was "you guys have +experience with the command line BE interface, so it will be easier to +test if you don't have to learn the DBT interface." The Debian people +have been doing this for a while though, so I imagine their email +interface is pretty good ;). + +Here's a short primer on my take on the DBT interface. + +The DBT has three main email addresses, each with it's own parsing style. + 1) creating bugs (submit@bugs.debian.org) + 2) commenting on bugs (<bug-number>@bugs.debian.org) + 3) controlling/managing bugs (control@bugs.debian.org) +I'm trying to squeeze these down into a single email address to avoid +having to tinker with the mail delivery system, so I've got everything +at (wking at tremily dot us) with subject tags: + 1) creating bugs + Subject: [be-bug:submit] new bug summary ... + 2) commenting on bugs + Subject: [be-bug:<bug-number>] human-specific subject + 3) control + Subject: [be-bug] human-specific subject + +The parsing styles each follow their DBT counterparts, but currently +have a much restricted breadth. + +The control-style consists of a list of allowed be commands, with one +command per line. Blank lines and lines beginning with '#' are +ignored, as well anything following a line starting with '--'. All the +listed commands are executed in order and their output returned. + +The comment-style interface appends a comment to the bug specified in +the subject tag. The the first non-multipart body is attached with +the appropriate content-type. In the case of "text/plain" contents, +anything following a line starting with '--' is stripped. + +The create-style interface creates a bug whose summary is given by the +email's post-tag subject. The body of the email must begin with a +psuedo-header containing at least the "Version" field. Anything after +the pseudo-header and before a line starting with '--' is, if present, +attached as the bugs first comment. + +Take a look at my interfaces/email/interactive/examples for some +examples. + +-- +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/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/a0e846ed-1549-4ec3-b94d-391e54610f61/values b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/a0e846ed-1549-4ec3-b94d-391e54610f61/values new file mode 100644 index 0000000..30de513 --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/a0e846ed-1549-4ec3-b94d-391e54610f61/values @@ -0,0 +1,14 @@ +Alt-id: <20090719130153.GA4036@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Sun, 19 Jul 2009 09:01:53 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + + +In-reply-to: cfd7cbc7-27ad-4618-8530-cb4d7323514a + diff --git a/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/cfd7cbc7-27ad-4618-8530-cb4d7323514a/body b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/cfd7cbc7-27ad-4618-8530-cb4d7323514a/body new file mode 100644 index 0000000..3db2a91 --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/cfd7cbc7-27ad-4618-8530-cb4d7323514a/body @@ -0,0 +1,26 @@ +"W. Trevor King" <wking@drexel.edu> writes: + +> The interface is basically "place your be command in the subject line" + +I would far prefer an interface of “place as many BE commands as you +like at the top of the message body, ending with an optional terminator +command, and they will each be executed in turn”. + +This would allow a single message to perform a batch of BE commands that +are related, instead of requiring to send each command in a separate +message. + +It would also leave the subject field free for something more +descriptive. The subject field could also be used as the summary field +of newly-created bug reports. With a terminator command, this would +allow the message to be sent both to BE and to some other recipient +(e.g. a mailing list) explaining the change. + +Have a look at the email interface of the Debian BTS for an example +<URL:http://www.debian.org/Bugs/server-request>. + +-- + \ “Pinky, are you pondering what I'm pondering?” “Wuh, I think | + `\ so, Brain, but will they let the Cranberry Duchess stay in the | +_o__) Lincoln Bedroom?” —_Pinky and The Brain_ | +Ben Finney diff --git a/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/cfd7cbc7-27ad-4618-8530-cb4d7323514a/values b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/cfd7cbc7-27ad-4618-8530-cb4d7323514a/values new file mode 100644 index 0000000..b98fbf7 --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/cfd7cbc7-27ad-4618-8530-cb4d7323514a/values @@ -0,0 +1,14 @@ +Alt-id: <87fxctbnce.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Sun, 19 Jul 2009 09:09:05 +1000 + + +From: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +In-reply-to: f1cde826-0506-4b4a-92ab-8499e953fa49 + diff --git a/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/f1cde826-0506-4b4a-92ab-8499e953fa49/body b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/f1cde826-0506-4b4a-92ab-8499e953fa49/body new file mode 100644 index 0000000..37b9936 --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/f1cde826-0506-4b4a-92ab-8499e953fa49/body @@ -0,0 +1,38 @@ +I finally did something towards a useful interactive email interface +;). As per our new guidelines, I'll develop this feature in it's own +branch: + http://www.physics.drexel.edu/~wking/code/bzr/be-email + +The interface is basically "place your be command in the subject line" +with a few exceptions. Some examples: + Subject: [be-bug] list --status=all + Subject: [be-bug] show --xml ID + Subject: [be-bug] new + Subject: [be-bug] comment ID +In the case of "new", the bug description is extracted from the first +non-blank body line. In the case of "comment", the email body is used +as the comment. Currently only "list", "show", "new", and "comment" +are allowed. + +You should get a reply email with exit status, stdout, and stderr from +your command. + +Send some mail to [wking (at) tremily (dot) us] to try it out! Depending +on spam attraction, this might be a limited time offer ;). + +Hopefully this lowers the entry barrier for bug reporting :). + +Disclaimer: I imaging the current implementation will choke on +non-text/plain content types. Also possibly on non-ascii encodings. +Probably lots of other bugs too... ;). For example, I should probably +allow the "help" command ... ;). + +Cheers, +Trevor + +-- +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/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/f1cde826-0506-4b4a-92ab-8499e953fa49/values b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/f1cde826-0506-4b4a-92ab-8499e953fa49/values new file mode 100644 index 0000000..3f81305 --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/f1cde826-0506-4b4a-92ab-8499e953fa49/values @@ -0,0 +1,11 @@ +Alt-id: <20090716133930.GC12213@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Thu, 16 Jul 2009 09:39:30 -0400 + + +From: '"W. Trevor King" <wking@drexel.edu>' + diff --git a/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/fba8de97-9c61-4a08-b3e7-d8a95d6efe54/body b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/fba8de97-9c61-4a08-b3e7-d8a95d6efe54/body new file mode 100644 index 0000000..167cfe5 --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/fba8de97-9c61-4a08-b3e7-d8a95d6efe54/body @@ -0,0 +1,10 @@ +Hi Trevor, + + > I finally did something towards a useful interactive email + > interface ;). + +Wow, nice! That'll be really useful. + +- Chris. +-- +Chris Ball <cjb@laptop.org> diff --git a/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/fba8de97-9c61-4a08-b3e7-d8a95d6efe54/values b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/fba8de97-9c61-4a08-b3e7-d8a95d6efe54/values new file mode 100644 index 0000000..f5da0c9 --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/comments/fba8de97-9c61-4a08-b3e7-d8a95d6efe54/values @@ -0,0 +1,14 @@ +Alt-id: <m3fxct5vl6.fsf@pullcord.laptop.org> + + +Content-type: text/plain + + +Date: Sat, 18 Jul 2009 21:07:33 -0400 + + +From: Chris Ball <cjb@laptop.org> + + +In-reply-to: f1cde826-0506-4b4a-92ab-8499e953fa49 + diff --git a/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/values b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/values new file mode 100644 index 0000000..5be4cca --- /dev/null +++ b/.be/bugs/e0858b12-0be3-49bb-ad7a-030e488bb2f1/values @@ -0,0 +1,20 @@ +assigned: W. Trevor King <wking@drexel.edu> + + +creator: W. Trevor King <wking@drexel.edu> + + +reporter: W. Trevor King <wking@drexel.edu> + + +severity: wishlist + + +status: assigned + + +summary: Interactive email interface + + +time: Tue, 21 Jul 2009 18:53:50 +0000 + |