diff options
Diffstat (limited to '.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957')
2 files changed, 109 insertions, 0 deletions
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 + |