aboutsummaryrefslogtreecommitdiffstats
path: root/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body
diff options
context:
space:
mode:
authorW. Trevor King <wking@drexel.edu>2009-07-21 15:22:09 -0400
committerW. Trevor King <wking@drexel.edu>2009-07-21 15:22:09 -0400
commit9ef8e376212786d8a99cfa19bfcd9c6e70735d0a (patch)
tree50d05dc3394845e1d1fd172be9125102d07ad43e /.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body
parent949b17853e384d4bce85a2ab0b29cf28375465aa (diff)
downloadbugseverywhere-9ef8e376212786d8a99cfa19bfcd9c6e70735d0a.tar.gz
I imported a few threads from the mailing list as wishlist bugs.
12c:uw: Bug aggregation. Multi-repo meta-BE? 529:ow: How should we version BE? 2f0:aw: Static html report generation 22b:aw: Sorting targets chronologically d99:aw: CherryPy interface "Cherry-flavored BE" e08:aw: Interactive email interface
Diffstat (limited to '.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body')
-rw-r--r--.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body95
1 files changed, 95 insertions, 0 deletions
diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body
new file mode 100644
index 0000000..debd486
--- /dev/null
+++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body
@@ -0,0 +1,95 @@
+On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
+> On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
+> > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
+> > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
+> > > > 1. is there any way to aggregate over multiple public branches in order
+> > > > to get the complete bug state
+> > >
+> > > Keeping the bug data with the source helps synchronize bug state and
+> > > source code. Bug state in branch A may not apply to branch B. Some
+> > > people like to weaken this source-bug linkage by keeping their bugs in
+> > > a branch all by themselves (ditz [http://ditz.rubyforge.org/]
+> > > currently supports this workflow). It sounds like you want to move
+> > > from "bugs with code" to "bugs and code in separate branches". We
+> > > don't have an easy way to do that in BE at the moment, since
+> > > version-control systems like Git have a single working branch at a
+> > > time (I think :p). What VCS are you using as a backend?
+> >
+> > the basic idea is to take a look at all public branches (for exaple all
+> > on lp/bitbucket/github) in order to tell the user of a webinterface that
+> > bug foo is fixed in branch xyz, and if its merged to the main branch
+>
+> Hmm.
+>
+> > > > 2. is there any model for storing bigger files at a central place (for
+> > > > some of my bugs i have multi-megabyte tarballs attached)
+> > >
+> > > be comment ID "See the tarball at http://yourpage/something.tar.gz"
+> > > Then to grab the tarball, you'd use:
+> > > wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
+> > > to grab it.
+> > so the basic idea is to do it completely self-managed
+>
+> Well, it's going to be managed by somebody ;). So far I'm not
+> convinced enough for the manager to be me, so I'm suggesting it be you
+> :p.
+>
+> > and have have heterogenous sources of extended data?
+>
+> I assume "extended data" here refers to your tarballs. What sort of
+> homogenous source did you have in mind? The comment body is currently
+> just a binary blob for non-text/* types, otherwise it's text in
+> whatever encoding you've configured.
+some kind of common upload target for a single project in order to have
+more reliable sources of stuff thats related to bugs but doesnt fit into
+the normal repository
+
+
+>
+> On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
+> > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
+> >
+> > > i want to see the combination of the bug data of all branches
+> >
+> > How is a tool to determine the set of “all branches”? The distributed
+> > VCS model means that set is indeterminate.
+>
+> He could just make a list of branches he likes.
+>
+> Ronny, are you looking to check bug status across several repos on the
+> fly, or periodically run something (with cron, etc.) to update a
+> static multi-repo summary?
+on the fly access
+
+>
+> The easiest implementation I can think of would be to keep local
+> branches (on whatever computer is hosting your web interface)
+> following your favorite repos.
+> proxectX/
+> |-- repoA
+> |-- repoB
+> `-- repoC
+> You'd pull upstream changes with a cron job.
+> Listing bugs would be something along the lines of
+> projectX$ for repo in *
+> do
+> pushd $repo
+> be list
+> popd
+> done | sort | uniq
+> Then to show bug status you would have something like
+> projectX$ for repo in *
+> do
+> echo $repo
+> pushd $repo
+> be show ${BUGID}
+> popd
+> done
+> For a web frontend, you'd want to translate that to python/libbe.
+>
+
+yes, the idea is to get a web fontend for multiple branches
+and maybe a local gtk fontend for local multi-branch setups
+
+for some of my projects i have n local and m remote repos, and merging
+is not always intended soonish