Bug: bea/12c

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?

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

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

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