diff options
Diffstat (limited to '.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331')
33 files changed, 0 insertions, 1003 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 deleted file mode 100644 index d3f00e7..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/body +++ /dev/null @@ -1,25 +0,0 @@ -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 deleted file mode 100644 index 4c93931..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/0f60a148-7024-44bd-bbed-377cbece9d1b/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index 1f6d84b..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/body +++ /dev/null @@ -1,28 +0,0 @@ -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 deleted file mode 100644 index a73aeeb..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/13012b22-2d02-444c-87c0-8cf0f17137ae/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index bd9e63a..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/body +++ /dev/null @@ -1,25 +0,0 @@ -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 deleted file mode 100644 index 55621fb..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/1f9f60de-ba37-42bc-a1c0-dc062ef255e1/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index 11f344c..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/body +++ /dev/null @@ -1,93 +0,0 @@ -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 deleted file mode 100644 index bb2305f..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index cf3c990..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/body +++ /dev/null @@ -1,32 +0,0 @@ -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 deleted file mode 100644 index 60c80a1..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/46937fd4-b0bc-4eed-8033-d699445441ea/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index c22de06..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/body +++ /dev/null @@ -1,73 +0,0 @@ -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 deleted file mode 100644 index b5ebf31..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/values +++ /dev/null @@ -1,14 +0,0 @@ -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/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body deleted file mode 100644 index e7b48e0..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/body +++ /dev/null @@ -1,83 +0,0 @@ -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/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values deleted file mode 100644 index adb1ae5..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/624a4542-92e9-442e-b71c-a14da4fe55cf/values +++ /dev/null @@ -1,8 +0,0 @@ -Author: W. Trevor King <wking@drexel.edu> - - -Content-type: text/plain - - -Date: Sat, 05 Dec 2009 22:39:07 +0000 - 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 deleted file mode 100644 index 6b7d3eb..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body +++ /dev/null @@ -1,70 +0,0 @@ -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 deleted file mode 100644 index bbeacb6..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index 2f2c16e..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/body +++ /dev/null @@ -1,15 +0,0 @@ -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 deleted file mode 100644 index a9cd364..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/88d1f2c2-e1af-4f0d-9390-e3c89ae4f7d7/values +++ /dev/null @@ -1,11 +0,0 @@ -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/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 deleted file mode 100644 index debd486..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body +++ /dev/null @@ -1,95 +0,0 @@ -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 deleted file mode 100644 index 5a64ee0..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index 5f55127..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/body +++ /dev/null @@ -1,87 +0,0 @@ -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 deleted file mode 100644 index dbdb347..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/bd98f525-95ec-446a-84e8-34c7d6fa5b40/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index cc3cff3..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/body +++ /dev/null @@ -1,37 +0,0 @@ -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 deleted file mode 100644 index 28fe7dc..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/c8283e08-967c-4a7b-b953-3ec62c83fb9f/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index 93f082b..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/body +++ /dev/null @@ -1,33 +0,0 @@ -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 deleted file mode 100644 index a79837f..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/d86e497d-667d-4c2b-9249-76026df56633/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index 3b417be..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/body +++ /dev/null @@ -1,27 +0,0 @@ -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 deleted file mode 100644 index 00fe043..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/dc32aa62-cf56-4171-84a1-8f7d02b23b6d/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index 0263fbb..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/body +++ /dev/null @@ -1,22 +0,0 @@ -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 deleted file mode 100644 index 2adef07..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/e520239c-8d69-4ff6-b1bd-0c2f74366200/values +++ /dev/null @@ -1,14 +0,0 @@ -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/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 deleted file mode 100644 index 9fb10bc..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/body +++ /dev/null @@ -1,26 +0,0 @@ -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 deleted file mode 100644 index fc2560e..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/fd6162f3-7fc1-41d1-a073-a07465802b72/values +++ /dev/null @@ -1,14 +0,0 @@ -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 - diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/values deleted file mode 100644 index 2a3c4f3..0000000 --- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/values +++ /dev/null @@ -1,17 +0,0 @@ -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 - |