diff options
167 files changed, 4464 insertions, 119 deletions
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 + @@ -39,7 +39,7 @@ MODULES += ${DOC_DIR} RM = rm PREFIX = /usr/local -PREFIX = ${HOME} +#PREFIX = ${HOME} #INSTALL_OPTIONS = "--prefix=${PREFIX}" @@ -68,3 +68,12 @@ later. In recognition of this, cmdutil provides the default_complete function which ensures that if '--complete' is any one of the arguments, options, or option-arguments, GetCompletions will be raised with and empty list. + +Profiling +========= + +Find out which 20 calls take the most cumulative time (time of +execution + childrens' times). + + $ python -m cProfile -o profile be [command] [args] + $ python -c "import pstats; p=pstats.Stats('profile'); p.sort_stats('cumulative').print_stats(20)" diff --git a/becommands/comment.py b/becommands/comment.py index 918f922..9408b09 100644 --- a/becommands/comment.py +++ b/becommands/comment.py @@ -158,7 +158,7 @@ def execute(args, manipulate_encodings=True): kids = [c.uuid for c in parent.traverse()] for nc in new_comments: assert nc.uuid in kids, "%s wasn't added to %s" % (nc.uuid, parent.uuid) - bd.save() + nc.save() def get_parser(): parser = cmdutil.CmdOptionParser("be comment ID [COMMENT]") diff --git a/becommands/depend.py b/becommands/depend.py index 977edae..201c2ea 100644 --- a/becommands/depend.py +++ b/becommands/depend.py @@ -59,7 +59,6 @@ def execute(args, manipulate_encodings=True): else: # add the dependency estrs.append(depend_string) bugA.extra_strings = estrs # reassign to notice change - bugA.save() depends = [] for estr in bugA.extra_strings: diff --git a/becommands/diff.py b/becommands/diff.py index 20fcb4c..50dea7c 100644 --- a/becommands/diff.py +++ b/becommands/diff.py @@ -24,10 +24,10 @@ def execute(args, manipulate_encodings=True): """ >>> import os >>> bd = bugdir.simple_bug_dir() + >>> bd.set_sync_with_disk(True) >>> original = bd.rcs.commit("Original status") >>> bug = bd.bug_from_uuid("a") >>> bug.status = "closed" - >>> bd.save() >>> changed = bd.rcs.commit("Closed bug a") >>> os.chdir(bd.root) >>> if bd.rcs.versioned == True: @@ -89,9 +89,10 @@ def get_parser(): return parser longhelp=""" -Uses the RCS to compare the current tree with a previous tree, and prints -a pretty report. If specifier is given, it is a specifier for the particular -previous tree to use. Specifiers are specific to their RCS. +Uses the RCS to compare the current tree with a previous tree, and +prints a pretty report. If REVISION is given, it is a specifier for +the particular previous tree to use. Specifiers are specific to their +RCS. For Arch your specifier must be a fully-qualified revision name. diff --git a/becommands/merge.py b/becommands/merge.py index c7cae2b..8e1fd50 100644 --- a/becommands/merge.py +++ b/becommands/merge.py @@ -22,6 +22,7 @@ def execute(args, manipulate_encodings=True): """ >>> from libbe import utility >>> bd = bugdir.simple_bug_dir() + >>> bd.set_sync_with_disk(True) >>> a = bd.bug_from_shortname("a") >>> a.comment_root.time = 0 >>> dummy = a.new_comment("Testing") @@ -35,7 +36,6 @@ def execute(args, manipulate_encodings=True): >>> dummy.time = 1 >>> dummy = dummy.new_reply("1 2 3 4") >>> dummy.time = 2 - >>> bd.save() >>> os.chdir(bd.root) >>> execute(["a", "b"], manipulate_encodings=False) Merging bugs a and b @@ -141,13 +141,13 @@ def execute(args, manipulate_encodings=True): bugB.load_comments() mergeA = bugA.new_comment("Merged from bug %s" % bugB.uuid) newCommTree = copy.deepcopy(bugB.comment_root) - for comment in newCommTree.traverse(): + for comment in newCommTree.traverse(): # all descendant comments comment.bug = bugA - for comment in newCommTree: + comment.save() # force onto disk under bugA + for comment in newCommTree: # just the child comments mergeA.add_reply(comment, allow_time_inversion=True) bugB.new_comment("Merged into bug %s" % bugA.uuid) bugB.status = "closed" - bd.save() print "Merging bugs %s and %s" % (bugA.uuid, bugB.uuid) def get_parser(): diff --git a/becommands/new.py b/becommands/new.py index 8512e22..2487bac 100644 --- a/becommands/new.py +++ b/becommands/new.py @@ -59,7 +59,6 @@ def execute(args, manipulate_encodings=True): bug.assigned = options.assigned elif bd.default_assignee != None: bug.assigned = bd.default_assignee - bd.save() print "Created bug with ID %s" % bd.bug_shortname(bug) def get_parser(): diff --git a/becommands/open.py b/becommands/open.py index ee81422..b98463d 100644 --- a/becommands/open.py +++ b/becommands/open.py @@ -44,7 +44,6 @@ def execute(args, manipulate_encodings=True): manipulate_encodings=manipulate_encodings) bug = bd.bug_from_shortname(args[0]) bug.status = "open" - bd.save() def get_parser(): parser = cmdutil.CmdOptionParser("be open BUG-ID") diff --git a/becommands/remove.py b/becommands/remove.py index d6ba999..884b792 100644 --- a/becommands/remove.py +++ b/becommands/remove.py @@ -44,7 +44,6 @@ def execute(args, manipulate_encodings=True): manipulate_encodings=manipulate_encodings) bug = bd.bug_from_shortname(args[0]) bd.remove_bug(bug) - bd.save() print "Removed bug %s" % bug.uuid def get_parser(): diff --git a/becommands/set.py b/becommands/set.py index 7bef644..f7fca54 100644 --- a/becommands/set.py +++ b/becommands/set.py @@ -62,7 +62,7 @@ def execute(args, manipulate_encodings=True): print _value_string(bd, args[0]) else: if args[1] == "none": - del bd.settings[args[0]] + setattr(bd, args[0], settings_object.EMPTY) else: if args[0] not in bd.settings_properties: msg = "Invalid setting %s\n" % args[0] @@ -71,7 +71,6 @@ def execute(args, manipulate_encodings=True): raise cmdutil.UserError(msg) old_setting = bd.settings.get(args[0]) setattr(bd, args[0], args[1]) - bd.save() def get_parser(): parser = cmdutil.CmdOptionParser("be set [NAME] [VALUE]") diff --git a/becommands/severity.py b/becommands/severity.py index 4e95638..d125789 100644 --- a/becommands/severity.py +++ b/becommands/severity.py @@ -51,7 +51,6 @@ def execute(args, manipulate_encodings=True): if e.name != "severity": raise e raise cmdutil.UserError ("Invalid severity level: %s" % e.value) - bd.save() def get_parser(): parser = cmdutil.CmdOptionParser("be severity BUG-ID [SEVERITY]") diff --git a/becommands/show.py b/becommands/show.py index ae1c7f3..b7bfe78 100644 --- a/becommands/show.py +++ b/becommands/show.py @@ -59,6 +59,8 @@ def execute(args, manipulate_encodings=True): raise cmdutil.UsageError bd = bugdir.BugDir(from_disk=True, manipulate_encodings=manipulate_encodings) + if options.XML: + print '<?xml version="1.0" encoding="%s" ?>' % bd.encoding for shortname in args: if shortname.count(':') > 1: raise cmdutil.UserError("Invalid id '%s'." % shortname) @@ -69,32 +71,37 @@ def execute(args, manipulate_encodings=True): else: bugname = shortname is_comment = False + if is_comment == True and options.comments == False: + continue bug = bd.bug_from_shortname(bugname) if is_comment == False: - if options.dumpXML: - print '<?xml version="1.0" encoding="%s" ?>' % bd.encoding - print bug.xml(show_comments=True) + if options.XML: + print bug.xml(show_comments=options.comments) else: - print bug.string(show_comments=True) + print bug.string(show_comments=options.comments) else: comment = bug.comment_root.comment_from_shortname( shortname, bug_shortname=bugname) - if options.dumpXML: + if options.XML: print comment.xml(shortname=shortname) else: if len(args) == 1 and options.only_raw_body == True: sys.__stdout__.write(comment.body) else: print comment.string(shortname=shortname) - if shortname != args[-1] and options.dumpXML == False: + if shortname != args[-1] and options.XML == False: print "" # add a blank line between bugs/comments def get_parser(): parser = cmdutil.CmdOptionParser("be show [options] ID [ID ...]") - parser.add_option("-x", "--xml", action="store_true", - dest='dumpXML', help="Dump as XML") + parser.add_option("-x", "--xml", action="store_true", default=False, + dest='XML', help="Dump as XML") parser.add_option("--only-raw-body", action="store_true", - dest='only_raw_body', help="When printing only a single comment, just print it's body. This allows extraction of non-text content types.") + dest='only_raw_body', + help="When printing only a single comment, just print it's body. This allows extraction of non-text content types.") + parser.add_option("-c", "--no-comments", dest="comments", + action="store_false", default=True, + help="Disable comment output. This is useful if you just want more details on a bug's current status.") return parser longhelp=""" diff --git a/becommands/status.py b/becommands/status.py index a122aec..56cb505 100644 --- a/becommands/status.py +++ b/becommands/status.py @@ -48,7 +48,6 @@ def execute(args, manipulate_encodings=True): if e.name != "status": raise raise cmdutil.UserError ("Invalid status: %s" % e.value) - bd.save() def get_parser(): parser = cmdutil.CmdOptionParser("be status BUG-ID [STATUS]") diff --git a/becommands/tag.py b/becommands/tag.py index 2932589..5c4b7a6 100644 --- a/becommands/tag.py +++ b/becommands/tag.py @@ -22,6 +22,7 @@ def execute(args, manipulate_encodings=True): """ >>> from libbe import utility >>> bd = bugdir.simple_bug_dir() + >>> bd.set_sync_with_disk(True) >>> os.chdir(bd.root) >>> a = bd.bug_from_shortname("a") >>> print a.extra_strings @@ -56,7 +57,6 @@ def execute(args, manipulate_encodings=True): >>> a.extra_strings = [] >>> print a.extra_strings [] - >>> a.save() >>> execute(["a"], manipulate_encodings=False) >>> bd._clear_bugs() # resync our copy of bug >>> a = bd.bug_from_shortname("a") @@ -103,7 +103,6 @@ def execute(args, manipulate_encodings=True): else: # add the tag estrs.append(tag_string) bug.extra_strings = estrs # reassign to notice change - bd.save() tags = [] for estr in bug.extra_strings: diff --git a/becommands/target.py b/becommands/target.py index 66bacb8..541918c 100644 --- a/becommands/target.py +++ b/becommands/target.py @@ -66,7 +66,6 @@ def execute(args, manipulate_encodings=True): bug.target = None else: bug.target = args[1] - bd.save() def get_parser(): parser = cmdutil.CmdOptionParser("be target BUG-ID [TARGET]\nor: be target --list") diff --git a/interfaces/xml/be-mbox-to-xml b/interfaces/xml/be-mbox-to-xml index a5bf13e..57de719 100755 --- a/interfaces/xml/be-mbox-to-xml +++ b/interfaces/xml/be-mbox-to-xml @@ -32,6 +32,8 @@ import types DEFAULT_ENCODING = get_encoding() set_IO_stream_encodings(DEFAULT_ENCODING) +KNOWN_IDS = [] + def comment_message_to_xml(message, fields=None): if fields == None: fields = {} @@ -51,6 +53,27 @@ def comment_message_to_xml(message, fields=None): new_fields.k = fields[k] fields = new_fields + if fields[u'in-reply-to'] == None: + if message[u'references'] != None: + refs = message[u'references'].split() + for ref in refs: # search for a known reference id. + if ref in KNOWN_IDS: + fields[u'in-reply-to'] = ref + break + if fields[u'in-reply-to'] == None and len(refs) > 0: + fields[u'in-reply-to'] = refs[0] # default to the first + else: # check for mutliple in-reply-to references. + refs = fields[u'in-reply-to'].split() + for ref in refs: # search for a known reference id. + if ref in KNOWN_IDS: + fields[u'in-reply-to'] = ref + break + if fields[u'in-reply-to'] == None and len(refs) > 0: + fields[u'in-reply-to'] = refs[0] # default to the first + + if fields['alt-id'] != None: + KNOWN_IDS.append(fields['alt-id']) + if message.is_multipart(): ret = [] alt_id = fields[u'alt-id'] @@ -61,9 +84,9 @@ def comment_message_to_xml(message, fields=None): continue fields[u'from'] = from_str fields[u'date'] = date - if len(ret) >= 0: - fields.pop(u'alt-id') - fields[u'in-reply-to'] = alt_id + if len(ret) > 0: # we've added one part already + fields.pop(u'alt-id') # don't pass alt-id to other parts + fields[u'in-reply-to'] = alt_id # others respond to first ret.append(comment_message_to_xml(m, fields)) return u'\n'.join(ret) @@ -71,7 +94,10 @@ def comment_message_to_xml(message, fields=None): #assert charset == DEFAULT_ENCODING.lower(), \ # u"Unknown charset: %s" % charset - encoding = message[u'content-transfer-encoding'].lower() + if message[u'content-transfer-encoding'] == None: + encoding = DEFAULT_ENCODING + else: + encoding = message[u'content-transfer-encoding'].lower() body = message.get_payload(decode=True) # attempt to decode assert body != None, "Unable to decode?" if fields[u'content-type'].startswith(u"text/"): diff --git a/libbe/bug.py b/libbe/bug.py index f5f479c..f3448e2 100644 --- a/libbe/bug.py +++ b/libbe/bug.py @@ -177,7 +177,7 @@ class Bug(settings_object.SavedSettingsObject): def time_string(): return {} def _get_time(self): - if self.time_string in [None, settings_object.EMPTY]: + if self.time_string == None: return None return utility.str_to_time(self.time_string) def _set_time(self, value): @@ -187,15 +187,8 @@ class Bug(settings_object.SavedSettingsObject): doc="An integer version of .time_string") def _extra_strings_check_fn(value): - "Require an iterable full of strings" - if value == settings_object.EMPTY: - return True - elif not hasattr(value, "__iter__"): - return False - for x in value: - if type(x) not in types.StringTypes: - return False - return True + return utility.iterable_full_of_strings(value, \ + alternative=settings_object.EMPTY) def _extra_strings_change_hook(self, old, new): self.extra_strings.sort() # to make merging easier self._prop_save_settings(old, new) @@ -252,12 +245,16 @@ class Bug(settings_object.SavedSettingsObject): def __repr__(self): return "Bug(uuid=%r)" % self.uuid + def set_sync_with_disk(self, value): + self.sync_with_disk = value + for comment in self.comments(): + comment.set_sync_with_disk(value) + def _setting_attr_string(self, setting): value = getattr(self, setting) - if value in [None, settings_object.EMPTY]: + if value == None: return "" - else: - return str(value) + return str(value) def xml(self, show_comments=False): if self.bugdir == None: @@ -372,10 +369,17 @@ class Bug(settings_object.SavedSettingsObject): mapfile.map_save(self.rcs, path, self._get_saved_settings()) def save(self): + """ + Save any loaded contents to disk. Because of lazy loading of + comments, this is actually not too inefficient. + + However, if self.sync_with_disk = True, then any changes are + automatically written to disk as soon as they happen, so + calling this method will just waste time (unless something + else has been messing with your on-disk files). + """ self.save_settings() - if len(self.comment_root) > 0: - self.rcs.mkdir(self.get_path("comments")) comment.saveComments(self) def remove(self): diff --git a/libbe/bugdir.py b/libbe/bugdir.py index 764e449..6e020ee 100644 --- a/libbe/bugdir.py +++ b/libbe/bugdir.py @@ -51,7 +51,7 @@ class NoRootEntry(Exception): class AlreadyInitialized(Exception): def __init__(self, path): self.path = path - Exception.__init__(self, + Exception.__init__(self, "Specified root is already initialized: %s" % path) class MultipleBugMatches(ValueError): @@ -70,7 +70,7 @@ class BugDir (list, settings_object.SavedSettingsObject): """ Sink to existing root ====================== - + Consider the following usage case: You have a bug directory rooted in /path/to/source @@ -85,23 +85,35 @@ class BugDir (list, settings_object.SavedSettingsObject): /path/to/source/GUI/.be miss /path/to/source/.be hit! So it still roots itself appropriately without much work for you. - + File-system access ================== - - When rooted in non-bugdir directory, BugDirs live completely in - memory until the first call to .save(). This creates a '.be' - sub-directory containing configurations options, bugs, comments, - etc. Once this sub-directory has been created (possibly by - another BugDir instance) any changes to the BugDir in memory will - be flushed to the file system automatically. However, the BugDir - will only load information from the file system when it loads new - bugs/comments that it doesn't already have in memory, or when it - explicitly asked to do so (e.g. .load() or __init__(from_disk=True)). - + + BugDirs live completely in memory when .sync_with_disk is False. + This is the default configuration setup by BugDir(from_disk=False). + If .sync_with_disk == True (e.g. BugDir(from_disk=True)), then + any changes to the BugDir will be immediately written to disk. + + If you want to change .sync_with_disk, we suggest you use + .set_sync_with_disk(), which propogates the new setting through to + all bugs/comments/etc. that have been loaded into memory. If + you've been living in memory and want to move to + .sync_with_disk==True, but you're not sure if anything has been + changed in memoryy, a call to save() is a safe move. + + Regardless of .sync_with_disk, a call to .save() will write out + all the contents that the BugDir instance has loaded into memory. + If sync_with_disk has been True over the course of all interesting + changes, this .save() call will be a waste of time. + + The BugDir will only load information from the file system when it + loads new bugs/comments that it doesn't already have in memory, or + when it explicitly asked to do so (e.g. .load() or + __init__(from_disk=True)). + Allow RCS initialization ======================== - + This one is for testing purposes. Setting it to True allows the BugDir to search for an installed RCS backend and initialize it in the root directory. This is a convenience option for supporting @@ -109,7 +121,7 @@ class BugDir (list, settings_object.SavedSettingsObject): Disable encoding manipulation ============================= - + This one is for testing purposed. You might have non-ASCII Unicode in your bugs, comments, files, etc. BugDir instances try and support your preferred encoding scheme (e.g. "utf-8") when @@ -141,10 +153,11 @@ class BugDir (list, settings_object.SavedSettingsObject): def _guess_encoding(self): return encoding.get_encoding() def _check_encoding(value): - if value != None and value != settings_object.EMPTY: + if value != None: return encoding.known_encoding(value) def _setup_encoding(self, new_encoding): - if new_encoding != None and new_encoding != settings_object.EMPTY: + # change hook called before generator. + if new_encoding not in [None, settings_object.EMPTY]: if self._manipulate_encodings == True: encoding.set_IO_stream_encodings(new_encoding) def _set_encoding(self, old_encoding, new_encoding): @@ -159,7 +172,7 @@ class BugDir (list, settings_object.SavedSettingsObject): def encoding(): return {} def _setup_user_id(self, user_id): - self.rcs.user_id = user_id + self.rcs.user_id = user_id def _guess_user_id(self): return self.rcs.get_user_id() def _set_user_id(self, old_user_id, new_user_id): @@ -214,7 +227,21 @@ settings easy. Don't set this attribute. Set .rcs instead, and if uuid not in map: map[uuid] = None self._bug_map_value = map # ._bug_map_value used by @local_property - + + def _extra_strings_check_fn(value): + return utility.iterable_full_of_strings(value, \ + alternative=settings_object.EMPTY) + def _extra_strings_change_hook(self, old, new): + self.extra_strings.sort() # to make merging easier + self._prop_save_settings(old, new) + @_versioned_property(name="extra_strings", + doc="Space for an array of extra strings. Useful for storing state for functionality implemented purely in becommands/<some_function>.py.", + default=[], + check_fn=_extra_strings_check_fn, + change_hook=_extra_strings_change_hook, + mutable=True) + def extra_strings(): return {} + @Property @primed_property(primer=_bug_map_gen) @local_property("bug_map") @@ -222,7 +249,7 @@ settings easy. Don't set this attribute. Set .rcs instead, and def _bug_map(): return {} def _setup_severities(self, severities): - if severities != None and severities != settings_object.EMPTY: + if severities not in [None, settings_object.EMPTY]: bug.load_severities(severities) def _set_severities(self, old_severities, new_severities): self._setup_severities(new_severities) @@ -269,7 +296,7 @@ settings easy. Don't set this attribute. Set .rcs instead, and # get a temporary rcs until we've loaded settings self.sync_with_disk = False self.rcs = self._guess_rcs() - + if from_disk == True: self.sync_with_disk = True self.load() @@ -283,6 +310,11 @@ settings easy. Don't set this attribute. Set .rcs instead, and self.rcs = rcs self._setup_user_id(self.user_id) + def set_sync_with_disk(self, value): + self.sync_with_disk = value + for bug in self: + bug.set_sync_with_disk(value) + def _find_root(self, path): """ Search for an existing bug database dir and it's ancestors and @@ -301,7 +333,7 @@ settings easy. Don't set this attribute. Set .rcs instead, and if beroot == None: raise NoBugDir(path) return beroot - + def get_version(self, path=None, use_none_rcs=False): if use_none_rcs == True: RCS = rcs.rcs_by_name("None") @@ -316,6 +348,7 @@ settings easy. Don't set this attribute. Set .rcs instead, and return tree_version def set_version(self): + self.rcs.mkdir(self.get_path()) self.rcs.set_file_contents(self.get_path("version"), TREE_VERSION_STRING) @@ -347,7 +380,7 @@ settings easy. Don't set this attribute. Set .rcs instead, and if not os.path.exists(self.get_path()): raise NoBugDir(self.get_path()) self.load_settings() - + self.rcs = rcs.rcs_by_name(self.rcs_name) self._setup_user_id(self.user_id) @@ -358,10 +391,17 @@ settings easy. Don't set this attribute. Set .rcs instead, and self._load_bug(uuid) def save(self): - self.rcs.mkdir(self.get_path()) + """ + Save any loaded contents to disk. Because of lazy loading of + bugs and comments, this is actually not too inefficient. + + However, if self.sync_with_disk = True, then any changes are + automatically written to disk as soon as they happen, so + calling this method will just waste time (unless something + else has been messing with your on-disk files). + """ self.set_version() self.save_settings() - self.rcs.mkdir(self.get_path("bugs")) for bug in self: bug.save() @@ -377,7 +417,7 @@ settings easy. Don't set this attribute. Set .rcs instead, and allow_no_rcs = not self.rcs.path_in_root(settings_path) # allow_no_rcs=True should only be for the special case of # configuring duplicate bugdir settings - + try: settings = mapfile.map_load(self.rcs, settings_path, allow_no_rcs) except rcs.NoSuchFile: @@ -392,6 +432,7 @@ settings easy. Don't set this attribute. Set .rcs instead, and allow_no_rcs = not self.rcs.path_in_root(settings_path) # allow_no_rcs=True should only be for the special case of # configuring duplicate bugdir settings + self.rcs.mkdir(self.get_path(), allow_no_rcs) mapfile.map_save(self.rcs, settings_path, settings, allow_no_rcs) def duplicate_bugdir(self, revision): @@ -442,6 +483,9 @@ settings easy. Don't set this attribute. Set .rcs instead, and def new_bug(self, uuid=None, summary=None): bg = bug.Bug(bugdir=self, uuid=uuid, summary=summary) + bg.set_sync_with_disk(self.sync_with_disk) + if bg.sync_with_disk == True: + bg.save() self.append(bg) self._bug_map_gen() return bg @@ -455,7 +499,7 @@ settings easy. Don't set this attribute. Set .rcs instead, and Generate short names from uuids. Picks the minimum number of characters (>=3) from the beginning of the uuid such that the short names are unique. - + Obviously, as the number of bugs in the database grows, these short names will cease to be unique. The complete uuid should be used for long term reference. @@ -502,7 +546,7 @@ settings easy. Don't set this attribute. Set .rcs instead, and if bug_uuid not in self._bug_map: return False return True - + def simple_bug_dir(): """ @@ -591,14 +635,17 @@ class BugDirTestCase(unittest.TestCase): self.failUnless(bugA == bugAprime, "%s != %s" % (bugA, bugAprime)) self.bugdir.save() self.versionTest() - def testComments(self): + def testComments(self, sync_with_disk=False): + if sync_with_disk == True: + self.bugdir.set_sync_with_disk(True) self.bugdir.new_bug(uuid="a", summary="Ant") bug = self.bugdir.bug_from_uuid("a") comm = bug.comment_root rep = comm.new_reply("Ants are small.") rep.new_reply("And they have six legs.") - self.bugdir.save() - self.bugdir._clear_bugs() + if sync_with_disk == False: + self.bugdir.save() + self.bugdir._clear_bugs() bug = self.bugdir.bug_from_uuid("a") bug.load_comments() self.failUnless(len(bug.comment_root)==1, len(bug.comment_root)) @@ -622,6 +669,8 @@ class BugDirTestCase(unittest.TestCase): comment.body) else: self.failIf(True, "Invalid comment: %d\n%s" % (index, comment)) + def testSyncedComments(self): + self.testComments(sync_with_disk=True) unitsuite = unittest.TestLoader().loadTestsFromTestCase(BugDirTestCase) suite = unittest.TestSuite([unitsuite])#, doctest.DocTestSuite()]) diff --git a/libbe/comment.py b/libbe/comment.py index e2f4ba7..3249e8b 100644 --- a/libbe/comment.py +++ b/libbe/comment.py @@ -123,6 +123,7 @@ def loadComments(bug, load_full=False): if uuid.startswith('.'): continue comm = Comment(bug, uuid, from_disk=True) + comm.set_sync_with_disk(bug.sync_with_disk) if load_full == True: comm.load_settings() dummy = comm.body # force the body to load @@ -130,8 +131,6 @@ def loadComments(bug, load_full=False): return list_to_root(comments, bug) def saveComments(bug): - path = bug.get_path("comments") - bug.rcs.mkdir(path) for comment in bug.comment_root.traverse(): comment.save() @@ -219,6 +218,20 @@ class Comment(Tree, settings_object.SavedSettingsObject): @doc_property(doc="A revision control system instance.") def rcs(): return {} + def _extra_strings_check_fn(value): + return utility.iterable_full_of_strings(value, \ + alternative=settings_object.EMPTY) + def _extra_strings_change_hook(self, old, new): + self.extra_strings.sort() # to make merging easier + self._prop_save_settings(old, new) + @_versioned_property(name="extra_strings", + doc="Space for an array of extra strings. Useful for storing state for functionality implemented purely in becommands/<some_function>.py.", + default=[], + check_fn=_extra_strings_check_fn, + change_hook=_extra_strings_change_hook, + mutable=True) + def extra_strings(): return {} + def __init__(self, bug=None, uuid=None, from_disk=False, in_reply_to=None, body=None): """ @@ -249,6 +262,9 @@ class Comment(Tree, settings_object.SavedSettingsObject): self.in_reply_to = in_reply_to self.body = body + def set_sync_with_disk(self, value): + self.sync_with_disk = True + def traverse(self, *args, **kwargs): """Avoid working with the possible dummy root comment""" for comment in Tree.traverse(self, *args, **kwargs): @@ -258,10 +274,9 @@ class Comment(Tree, settings_object.SavedSettingsObject): def _setting_attr_string(self, setting): value = getattr(self, setting) - if value in [None, settings_object.EMPTY]: + if value == None: return "" - else: - return str(value) + return str(value) def xml(self, indent=0, shortname=None): """ @@ -430,13 +445,19 @@ class Comment(Tree, settings_object.SavedSettingsObject): self._setup_saved_settings() def save_settings(self): - parent_dir = os.path.dirname(self.get_path()) - self.rcs.mkdir(parent_dir) self.rcs.mkdir(self.get_path()) path = self.get_path("values") mapfile.map_save(self.rcs, path, self._get_saved_settings()) def save(self): + """ + Save any loaded contents to disk. + + However, if self.sync_with_disk = True, then any changes are + automatically written to disk as soon as they happen, so + calling this method will just waste time (unless something + else has been messing with your on-disk files). + """ assert self.body != None, "Can't save blank comment" self.save_settings() self._set_comment_body(new=self.body, force=True) @@ -461,6 +482,10 @@ class Comment(Tree, settings_object.SavedSettingsObject): True """ reply = Comment(self.bug, body=body) + if self.bug != None: + reply.set_sync_with_disk(self.bug.sync_with_disk) + if reply.sync_with_disk == True: + reply.save() self.add_reply(reply) return reply diff --git a/libbe/properties.py b/libbe/properties.py index e9affcb..144220b 100644 --- a/libbe/properties.py +++ b/libbe/properties.py @@ -52,7 +52,7 @@ def Property(funcs): args["fset"] = funcs.get("fset", None) args["fdel"] = funcs.get("fdel", None) args["doc"] = funcs.get("doc", None) - + #print "Creating a property with" #for key, val in args.items(): print key, value return property(**args) @@ -77,6 +77,9 @@ def local_property(name, null=None, mutable_null=False): Define get/set access to per-parent-instance local storage. Uses ._<name>_value to store the value for a particular owner instance. If the ._<name>_value attribute does not exist, returns null. + + If mutable_null == True, we only release deepcopies of the null to + the outside world. """ def decorator(funcs): if hasattr(funcs, "__call__"): @@ -166,11 +169,16 @@ def _cmp_cached_mutable_property(self, cacher_name, property_name, value): def defaulting_property(default=None, null=None, - default_mutable=False, - null_mutable=False): + mutable_default=False): """ Define a default value for get access to a property. If the stored value is null, then default is returned. + + If mutable_default == True, we only release deepcopies of the + default to the outside world. + + null should never escape to the outside world, so don't worry + about it being a mutable. """ def decorator(funcs): if hasattr(funcs, "__call__"): @@ -181,17 +189,14 @@ def defaulting_property(default=None, null=None, def _fget(self): value = fget(self) if value == null: - if default_mutable == True: + if mutable_default == True: return copy.deepcopy(default) else: return default return value def _fset(self, value): if value == default: - if null_mutable == True: - value = copy.deepcopy(null) - else: - value = null + value = null fset(self, value) funcs["fget"] = _fget funcs["fset"] = _fset @@ -261,7 +266,7 @@ def cached_property(generator, initVal=None, mutable=False): If the input value is no longer initVal (e.g. a value has been loaded from disk or set with fset), that value overrides any cached value, and this property has no effect. - + When the cache flag is False and the stored value is initVal, the generator is not cached, but is called on every fget. @@ -270,7 +275,7 @@ def cached_property(generator, initVal=None, mutable=False): In the case that mutable == True, all caching is disabled and the generator is called whenever the cached value would otherwise be - used. This avoids uncertainties in the value of stored mutables. + used. """ def decorator(funcs): if hasattr(funcs, "__call__"): @@ -296,7 +301,7 @@ def cached_property(generator, initVal=None, mutable=False): def primed_property(primer, initVal=None): """ - Just like a generator_property, except that instead of returning a + Just like a cached_property, except that instead of returning a new value and running fset to cache it, the primer performs some background manipulation (e.g. loads data into instance.settings) such that a _second_ pass through fget succeeds. @@ -331,6 +336,17 @@ def change_hook_property(hook, mutable=False): called _after_ the new value has been stored, allowing you to change the stored value if you want. + In the case of mutables, things are slightly trickier. Because + the property-owning class has no way of knowing when the value + changes. We work around this by caching a private deepcopy of the + mutable value, and checking for changes whenever the property is + set (obviously) or retrieved (to check for external changes). So + long as you're conscientious about accessing the property after + making external modifications, mutability woln't be a problem. + t.x.append(5) # external modification + t.x # dummy access notices change and triggers hook + See testChangeHookMutableProperty for an example of the expected + behavior. """ def decorator(funcs): if hasattr(funcs, "__call__"): @@ -339,7 +355,10 @@ def change_hook_property(hook, mutable=False): fset = funcs.get("fset") name = funcs.get("name", "<unknown>") def _fget(self, new_value=None, from_fset=False): # only used if mutable == True - value = fget(self) + if from_fset == True: + value = new_value # compare new value with cached + else: + value = fget(self) # compare current value with cached if _cmp_cached_mutable_property(self, "change hook property", name, value) != 0: # there has been a change, cache new value old_value = _get_cached_mutable_property(self, "change hook property", name) @@ -362,7 +381,7 @@ def change_hook_property(hook, mutable=False): funcs["fset"] = _fset return funcs return decorator - + class DecoratorTests(unittest.TestCase): def testLocalDoc(self): @@ -406,7 +425,7 @@ class DecoratorTests(unittest.TestCase): @local_property(name="DEFAULT", null=5) def x(): return {} t = Test() - self.failUnless(t.x == 5, str(t.x)) + self.failUnless(t.x == 5, str(t.x)) t.x = 'x' self.failUnless(t.x == 'y', str(t.x)) t.x = 'y' @@ -575,14 +594,17 @@ class DecoratorTests(unittest.TestCase): t.x = [] self.failUnless(t.old == None, t.old) self.failUnless(t.new == [], t.new) + self.failUnless(t.hook_calls == 1, t.hook_calls) a = t.x a.append(5) t.x = a self.failUnless(t.old == [], t.old) self.failUnless(t.new == [5], t.new) + self.failUnless(t.hook_calls == 2, t.hook_calls) t.x = [] self.failUnless(t.old == [5], t.old) self.failUnless(t.new == [], t.new) + self.failUnless(t.hook_calls == 3, t.hook_calls) # now append without reassigning. this doesn't trigger the # change, since we don't ever set t.x, only get it and mess # with it. It does, however, update our t.new, since t.new = @@ -590,25 +612,26 @@ class DecoratorTests(unittest.TestCase): t.x.append(5) self.failUnless(t.old == [5], t.old) self.failUnless(t.new == [5], t.new) + self.failUnless(t.hook_calls == 3, t.hook_calls) # however, the next t.x get _will_ notice the change... a = t.x self.failUnless(t.old == [], t.old) self.failUnless(t.new == [5], t.new) - self.failUnless(t.hook_calls == 6, t.hook_calls) + self.failUnless(t.hook_calls == 4, t.hook_calls) t.x.append(6) # this append(6) is not noticed yet self.failUnless(t.old == [], t.old) self.failUnless(t.new == [5,6], t.new) - self.failUnless(t.hook_calls == 6, t.hook_calls) + self.failUnless(t.hook_calls == 4, t.hook_calls) # this append(7) is not noticed, but the t.x get causes the # append(6) to be noticed t.x.append(7) self.failUnless(t.old == [5], t.old) self.failUnless(t.new == [5,6,7], t.new) - self.failUnless(t.hook_calls == 7, t.hook_calls) + self.failUnless(t.hook_calls == 5, t.hook_calls) a = t.x # now the append(7) is noticed self.failUnless(t.old == [5,6], t.old) self.failUnless(t.new == [5,6,7], t.new) - self.failUnless(t.hook_calls == 8, t.hook_calls) + self.failUnless(t.hook_calls == 6, t.hook_calls) suite = unittest.TestLoader().loadTestsFromTestCase(DecoratorTests) diff --git a/libbe/rcs.py b/libbe/rcs.py index 3bf8c9d..1e1cfa7 100644 --- a/libbe/rcs.py +++ b/libbe/rcs.py @@ -339,11 +339,15 @@ class RCS(object): self.add(path) else: self.update(path) - def mkdir(self, path, allow_no_rcs=False): + def mkdir(self, path, allow_no_rcs=False, check_parents=True): """ Create (if neccessary) a directory at path under version control. """ + if check_parents == True: + parent = os.path.dirname(path) + if not os.path.exists(parent): # recurse through parents + self.mkdir(parent, allow_no_rcs, check_parents) if not os.path.exists(path): os.mkdir(path) if self._use_rcs(path, allow_no_rcs): @@ -351,7 +355,9 @@ class RCS(object): else: assert os.path.isdir(path) if self._use_rcs(path, allow_no_rcs): - self.update(path) + #self.update(path)# Don't update directories. Changing files + pass # underneath them should be sufficient. + def duplicate_repo(self, revision=None): """ Get the repository as it was in a given revision. diff --git a/libbe/settings_object.py b/libbe/settings_object.py index 9bc0a2f..dde247f 100644 --- a/libbe/settings_object.py +++ b/libbe/settings_object.py @@ -96,7 +96,7 @@ def versioned_property(name, doc, require_save=False): """ Combine the common decorators in a single function. - + Use zero or one (but not both) of default or generator, since a working default will keep the generator from functioning. Use the default if you know what you want the default value to be at @@ -104,22 +104,29 @@ def versioned_property(name, doc, determine a valid default at run time. If both default and generator are None, then the property will be a defaulting property which defaults to None. - + allowed and check_fn have a similar relationship, although you can use both of these if you want. allowed compares the proposed value against a list determined at 'coding time' and check_fn allows more flexible comparisons to take place at run time. - + Set require_save to True if you want to save the default/generated value for a property, to protect against future changes. E.g., we currently expect all comments to be 'text/plain' but in the future we may want to default to 'text/html'. If we don't want the old comments to be interpreted as 'text/html', we would require that the content type be saved. - + change_hook, primer, settings_properties, and required_saved_properties are only options to get their defaults into our local scope. Don't mess with them. + + Set mutable=True if: + * default is a mutable + * your generator function may return mutables + * you set change_hook and might have mutable property values + See the docstrings in libbe.properties for details on how each of + these cases are handled. """ settings_properties.append(name) if require_save == True: @@ -128,7 +135,7 @@ def versioned_property(name, doc, fulldoc = doc if default != None or generator == None: defaulting = defaulting_property(default=default, null=EMPTY, - default_mutable=mutable) + mutable_default=mutable) fulldoc += "\n\nThis property defaults to %s." % default if generator != None: cached = cached_property(generator=generator, initVal=EMPTY, @@ -180,7 +187,7 @@ class SavedSettingsObject(object): # Override. Must call ._setup_saved_settings() after loading. self.settings = {} self._setup_saved_settings() - + def _setup_saved_settings(self, flag_as_loaded=True): """ To be run after setting self.settings up from disk. Marks all @@ -208,7 +215,7 @@ class SavedSettingsObject(object): for k in self.required_saved_properties: settings[k] = getattr(self, self._setting_name_to_attr_name(k)) return settings - + def clear_cached_setting(self, setting=None): "If setting=None, clear *all* cached settings" if setting != None: @@ -392,19 +399,17 @@ class SavedSettingsObjectTests(unittest.TestCase): self.failUnless(SAVES == [ "'None' -> '<class 'libbe.settings_object.EMPTY'>'", "'<class 'libbe.settings_object.EMPTY'>' -> '[]'", - "'<class 'libbe.settings_object.EMPTY'>' -> '[]'" # <- TODO. Where did this come from? ], SAVES) self.failUnless(t.settings["List-type"] == [5],t.settings["List-type"]) self.failUnless(SAVES == [ # the append(5) has not yet been saved "'None' -> '<class 'libbe.settings_object.EMPTY'>'", "'<class 'libbe.settings_object.EMPTY'>' -> '[]'", - "'<class 'libbe.settings_object.EMPTY'>' -> '[]'", ], SAVES) self.failUnless(t.list_type == [5], t.list_type) # <-get triggers saved + self.failUnless(SAVES == [ # now the append(5) has been saved. "'None' -> '<class 'libbe.settings_object.EMPTY'>'", "'<class 'libbe.settings_object.EMPTY'>' -> '[]'", - "'<class 'libbe.settings_object.EMPTY'>' -> '[]'", "'[]' -> '[5]'" ], SAVES) diff --git a/libbe/utility.py b/libbe/utility.py index f27d7eb..3df06b4 100644 --- a/libbe/utility.py +++ b/libbe/utility.py @@ -23,7 +23,6 @@ import time import types import doctest - def search_parent_directories(path, filename): """ Find the file (or directory) named filename in path or in any @@ -106,5 +105,25 @@ def time_to_gmtime(str_time): time_val = str_to_time(str_time) return time_to_str(time_val) +def iterable_full_of_strings(value, alternative=None): + """ + Require an iterable full of strings. + >>> iterable_full_of_strings([]) + True + >>> iterable_full_of_strings(["abc", "def", u"hij"]) + True + >>> iterable_full_of_strings(["abc", None, u"hij"]) + False + >>> iterable_full_of_strings(None, alternative=None) + True + """ + if value == alternative: + return True + elif not hasattr(value, "__iter__"): + return False + for x in value: + if type(x) not in types.StringTypes: + return False + return True suite = doctest.DocTestSuite() |