diff options
Diffstat (limited to '.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments')
32 files changed, 986 insertions, 0 deletions
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/body new file mode 100644 index 0000000..d3f00e7 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/values new file mode 100644 index 0000000..4c93931 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/values @@ -0,0 +1,14 @@ +Alt-id: <874otjmjhr.fsf@benfinney.id.au> + + +Author: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 23:34:08 +1000 + + +In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/body new file mode 100644 index 0000000..1f6d84b --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/values new file mode 100644 index 0000000..a73aeeb --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/values @@ -0,0 +1,14 @@ +Alt-id: <20090711125030.GA18185@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 08:50:30 -0400 + + +In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/body new file mode 100644 index 0000000..bd9e63a --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/values new file mode 100644 index 0000000..55621fb --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/values @@ -0,0 +1,14 @@ +Alt-id: <878wivmjm1.fsf@benfinney.id.au> + + +Author: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 23:31:34 +1000 + + +In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/body new file mode 100644 index 0000000..11f344c --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/values new file mode 100644 index 0000000..bb2305f --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/values @@ -0,0 +1,14 @@ +Alt-id: <20090713104715.GA13723@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Mon, 13 Jul 2009 06:47:15 -0400 + + +In-reply-to: 6dcc910a-ce15-4eeb-b49b-4747719748ed + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/body new file mode 100644 index 0000000..cf3c990 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/values new file mode 100644 index 0000000..60c80a1 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/values @@ -0,0 +1,14 @@ +Alt-id: <20090713115734.GA13788@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Mon, 13 Jul 2009 07:57:34 -0400 + + +In-reply-to: bd98f525-95ec-446a-84e8-34c7d6fa5b40 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/body new file mode 100644 index 0000000..c22de06 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/values new file mode 100644 index 0000000..b5ebf31 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/values @@ -0,0 +1,14 @@ +Alt-id: <20090712235502.GA10782@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sun, 12 Jul 2009 19:55:02 -0400 + + +In-reply-to: 8ffc90d7-0be7-4b00-88e6-9ae1b65f7957 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body new file mode 100644 index 0000000..e7b48e0 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body @@ -0,0 +1,83 @@ +I read + http://weblog.masukomi.org/2008/1/3/distributed-bug-tracking +yesterday, and the section on bug visibility got me thinking about +bug 12c (Multi-repo meta-BE?) some more. + +We already have interfaces like this email/html mashup: + +On Sun, Sep 13, 2009 at 07:04:05AM -0400, W. Trevor King wrote: +> Since the non-bzr interfaces to BE are coming along nicely, I've put +> up a non-bzr interface to my be-rr branch. +> http://www.physics.drexel.edu/~wking/code/be +> It uses nightly builds of Gianluca's static html from my devel branch +> to provide read-only browsing, and accepts changes from the general +> public through my email interface into a public branch. I handle the +> synchronization of these two branches manually. + +These interfaces provide a means for remote users to access a BE +repository without bzr or the command line. As far as users are +concerned, this exposed repository looks pretty much like a +centralized bugtracking system (e.g. bugzilla, ...). + +However, with BE we have more bug information living off in other +branches that haven't yet been merged with the exposed repo. The +problem is two-fold: + 1) how to keep up to date within a distributed community. + 2) how do users find branches/patches that fix bug XYZ. + +For (2), I think the best solution at the moment are along the lines +of my little scripts (discussed in the bug 12c comments). With the +addition of the `be diff --dir DIR` option, it's now even easier to +find more information on bug 565 (or whatever UUID): + be/be.wtk$ for repo in ../*; do \ + if [ $repo == "be.wtk" ]; then continue; fi; \ + diff=$(be diff --dir $repo --subscribe 565:all); \ + if [ -n "$diff" ]; then \ + echo "Changed from $repo:"; echo "$diff"; \ + fi; \ + done + Changed from ../be.html: + New bugs: + 565:fm: be email-bugs for bug submission from bzr-less users + Changed from ../be.trunk: + New bugs: + 565:fm: be email-bugs for bug submission from bzr-less users + Changed from ../cherryflavoredbugseverywhere: + New bugs: + 565:fm: be email-bugs for bug submission from bzr-less users +where the --dir and --subscribe options to `be diff` are new. If +people don't like the command line, this would be easy to bundle into +a web-frontend (CFBE?) if you wanted, with a cron job pulling updates +into the tracked branches. + +I was starting into a solution for (1) when I did this: + +On Mon, Jul 27, 2009 at 08:42:19AM -0400, W. Trevor King wrote: +> My email interface now supports subscription: +> be subscribe DIR # see any changes to the bug directory. +> be subscribe BUG-ID # see changes to a particular bug. +> See +> be subscribe --help +> for more details. + +The idea was that a dev/user would subscribe to whatever issues they +wanted to track, and they would get email notifications whenever some +action affected any of those issues. These subscriptions would +percolate through the distributed branches as a result of the usual +mergers. For example, my subscription to all changes has made it into +the trunk branch (see .be/settings). + +This subscription mechanism was setup to work through interactive +public interfaces (my email interface, eventually CFBE, ...), but +it doesn't work for changes made via the command-line interface, +so I browsed around a bit and ran across some interesting workflows +in the bzr documentation + doc/developers/HACKING.txt, "Communicating and Coordinating" +which points out the following plugins + * email (http://doc.bazaar-vcs.org/plugins/en/email-plugin.html) + * dbus (http://doc.bazaar-vcs.org/plugins/en/dbus-plugin.html) +which send automatic notification messages after commits, etc. If +people want this sort of functionality, it would be easy enough to rig +a hook for `be commit' that sent a diff email to subscribers, which +could include be-devel. + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values new file mode 100644 index 0000000..adb1ae5 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values @@ -0,0 +1,8 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sat, 05 Dec 2009 22:39:07 +0000 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body new file mode 100644 index 0000000..6b7d3eb --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/values new file mode 100644 index 0000000..bbeacb6 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/values @@ -0,0 +1,14 @@ +Alt-id: <1247468734.7189.1.camel@localhost> + + +Author: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> + + +Content-type: text/plain + + +Date: Mon, 13 Jul 2009 09:05:34 +0200 + + +In-reply-to: 4d192c6c-a4a8-4844-b083-2dd5926bd2d9 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/body new file mode 100644 index 0000000..2f2c16e --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/values new file mode 100644 index 0000000..a9cd364 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/values @@ -0,0 +1,11 @@ +Alt-id: <1247313294.7701.60.camel@localhost> + + +Author: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 13:54:54 +0200 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body new file mode 100644 index 0000000..debd486 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values new file mode 100644 index 0000000..5a64ee0 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values @@ -0,0 +1,14 @@ +Alt-id: <1247433610.14803.3.camel@localhost> + + +Author: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> + + +Content-type: text/plain + + +Date: Sun, 12 Jul 2009 23:20:10 +0200 + + +In-reply-to: bd98f525-95ec-446a-84e8-34c7d6fa5b40 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body new file mode 100644 index 0000000..5f55127 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/values new file mode 100644 index 0000000..dbdb347 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/values @@ -0,0 +1,14 @@ +Alt-id: <20090711152507.GA18461@mjolnir.home.net> + + +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 11:25:07 -0400 + + +In-reply-to: e520239c-8d69-4ff6-b1bd-0c2f74366200 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/body new file mode 100644 index 0000000..cc3cff3 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/values new file mode 100644 index 0000000..28fe7dc --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/values @@ -0,0 +1,14 @@ +Alt-id: <20090713085859.GA21800@grys.it> + + +Author: Gianluca Montecchi <gian@grys.it> + + +Content-type: text/plain + + +Date: Mon, 13 Jul 2009 10:58:59 +0200 + + +In-reply-to: e520239c-8d69-4ff6-b1bd-0c2f74366200 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/body new file mode 100644 index 0000000..93f082b --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/values new file mode 100644 index 0000000..a79837f --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/values @@ -0,0 +1,14 @@ +Alt-id: <1247320857.7701.67.camel@localhost> + + +Author: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 16:00:57 +0200 + + +In-reply-to: 0f60a148-7024-44bd-bbed-377cbece9d1b + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/body new file mode 100644 index 0000000..3b417be --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/values new file mode 100644 index 0000000..00fe043 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/values @@ -0,0 +1,14 @@ +Alt-id: <1247317985.7701.63.camel@localhost> + + +Author: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> + + +Content-type: text/plain + + +Date: Sat, 11 Jul 2009 15:13:05 +0200 + + +In-reply-to: 13012b22-2d02-444c-87c0-8cf0f17137ae + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/body new file mode 100644 index 0000000..0263fbb --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/values new file mode 100644 index 0000000..2adef07 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/values @@ -0,0 +1,14 @@ +Alt-id: <87zlbbl128.fsf@benfinney.id.au> + + +Author: Ben Finney <bignose+hates-spam@benfinney.id.au> + + +Content-type: text/plain + + +Date: Sun, 12 Jul 2009 00:57:35 +1000 + + +In-reply-to: 88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/body new file mode 100644 index 0000000..9fb10bc --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/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/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/values new file mode 100644 index 0000000..fc2560e --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/values @@ -0,0 +1,14 @@ +Alt-id: <20090713090341.GB21800@grys.it> + + +Author: Gianluca Montecchi <gian@grys.it> + + +Content-type: text/plain + + +Date: Mon, 13 Jul 2009 11:03:41 +0200 + + +In-reply-to: 1f9f60de-ba37-42bc-a1c0-dc062ef255e1 + |