any plans on suporting subrepos/submodules/nested trees as a mean to share bugs across the boundaries of branches?

hi,

just wondering if you guys would consider storing the bug database in a
subrepo in order to ease merging the bug database across branches
without actually merging the code as well.

-- Ronny Pfannschmidt

Re: any plans on suporting subrepos/submodules/nested trees as a mean to share bugs across the boundaries of branches?

On Wed, Jun 02, 2010 at 11:09:50PM +0200, Ronny Pfannschmidt wrote:
> hi,
> 
> just wondering if you guys would consider storing the bug database in a
> subrepo in order to ease merging the bug database across branches
> without actually merging the code as well.

As far as I know there is no plan, but probably Chris can be more precise.

bye
Gianluca

Re: any plans on suporting subrepos/submodules/nested trees as a mean to share bugs across the boundaries of branches?

On Wed, Jun 02, 2010 at 11:09:50PM +0200, Ronny Pfannschmidt wrote:
> just wondering if you guys would consider storing the bug database
> in a subrepo

what's wrong with:
  alias be='be -r /path/to/bug/repo'
?

--

-- 
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

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Re: any plans on suporting subrepos/submodules/nested trees as a mean to share bugs across the boundaries of branches?

Hi,

   > just wondering if you guys would consider storing the bug
   > database in a subrepo in order to ease merging the bug database
   > across branches without actually merging the code as well.

My intuition is that bugs *shouldn't* be merged across branches
without merging the code at the same time -- that just leads to the
bug database becoming out of sync with the code it's describing.
What's the advantage of having them out of sync?

- Chris.
--

-- 
Chris Ball   <cjb <at> laptop.org>
One Laptop Per Child

Re: any plans on suporting subrepos/submodules/nested trees as a mean to share bugs across the boundaries of branches?

On Fri, 2010-06-04 at 10:11 -0400, Chris Ball wrote:
> Hi,
> 
>    > just wondering if you guys would consider storing the bug
>    > database in a subrepo in order to ease merging the bug database
>    > across branches without actually merging the code as well.
> 
> My intuition is that bugs *shouldn't* be merged across branches
> without merging the code at the same time -- that just leads to the
> bug database becoming out of sync with the code it's describing.
> What's the advantage of having them out of sync?
> 

define out of sync, i don't want to argue for suddenly marking stuff
resolved on branches that don't yet have tho code changes

but i want to have some kind of central access
to the bug database for end-users and maintainers

and correctly moving stuff between bug databases for branches seems an
awful hell of weird cases unless the bug database is at least a bit
detachable and separately mergable

because right now stuff is very out of sync between branches

- Ronny

> - Chris.
> -- 
> Chris Ball   <cjb <at> laptop.org>

Re: any plans on suporting subrepos/submodules/nested trees as a mean to share bugs across the boundaries of branches?

On Fri, Jun 04, 2010 at 06:20:16AM -0400, W. Trevor King wrote:
> On Wed, Jun 02, 2010 at 11:09:50PM +0200, Ronny Pfannschmidt wrote:
> > just wondering if you guys would consider storing the bug database
> > in a subrepo
> 
> what's wrong with:
>   alias be='be -r /path/to/bug/repo'
> ?

Nothing except that you need to have all the branches downloaded to 
different directories.

And still you don't have a unique list but just some lists of bugs that you 
need to merge in some way.

Of course this is logical given how BE and the DVCSs work, but it can be a 
problem if you want to have a complete report of the bugs without having all
the branches downloaded and/or merged.

bye
Gianluca

Re: any plans on suporting subrepos/submodules/nested trees as a mean to share bugs across the boundaries of branches?

On Fri, Jun 04, 2010 at 10:11:59AM -0400, Chris Ball wrote:
> Hi,
> 
>    > just wondering if you guys would consider storing the bug
>    > database in a subrepo in order to ease merging the bug database
>    > across branches without actually merging the code as well.
> 
> My intuition is that bugs *shouldn't* be merged across branches
> without merging the code at the same time -- that just leads to the
> bug database becoming out of sync with the code it's describing.
> What's the advantage of having them out of sync?

Just to say the first that cross my mind: the possibility to publish on the 
web a complete list of bugs for a project, where it is logical to publish all
the bugs from all the branches.

But I agree with you on the fact that bugs and code must be always in sync.

bye
Gianluca

Re: any plans on suporting subrepos/submodules/nested trees as a mean to share bugs across the boundaries of branches?

Gianluca Montecchi <gian <at> grys.it> writes:

> On Fri, Jun 04, 2010 at 10:11:59AM -0400, Chris Ball wrote:
> > What's the advantage of having them out of sync?
>
> Just to say the first that cross my mind: the possibility to publish
> on the web a complete list of bugs for a project, where it is logical
> to publish all the bugs from all the branches.

The different branches will have bugs in different states. I assume we
don't want all the states of all the bugs in all the branches to be
published simultaneously; there must be some canonical state of the bug
database.

So you have to pick one branch to be the canonical version of the bug
database. To my understanding, it should be the branch that is also the
canonical “trunk” branch for the code.

What am I missing?

--

-- 
 \       “Know what I hate most? Rhetorical questions.” —Henry N. Camp |
  `\                                                                   |
_o__)                                                                  |
Ben Finney

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Re: any plans on suporting subrepos/submodules/nested trees as a mean to share bugs across the boundaries of branches?

On Fri, Jun 04, 2010 at 05:01:18PM +0200, Gianluca Montecchi wrote:
> Nothing except that you need to have all the branches downloaded to
> different directories.

"branches" gets a bit murky across our range of DCVSs.  Different
directories are not so much of a hassle, and it will make BE much
faster, since direct filesystem access is a lot faster than
filesystem-via-a-VCS.

> And still you don't have a unique list but just some lists of bugs that you 
> need to merge in some way.

On Fri, Jun 04, 2010 at 04:27:31PM +0200, Ronny Pfannschmidt wrote:
> but i want to have some kind of central access to the bug database
> for end-users and maintainers

If someone can give a clear description of the desired interface, one
of us will code it up sooner or later.  Suggested interface:

  be list -r repo1,repo2,repo3,repo4
which is not currently implemented, but would be pretty easy.

As well as
  be show -r repo1,repo2,repo3,repo4 ID
which would show the bug exactly like
  be show -r repo1 ID
except that
  Status : <repo1 status>
would become
  Status : <repo1>:<repo1 status>, <repo2>:<repo2 status>, ...

Re: any plans on suporting subrepos/submodules/nested trees as a mean to share bugs across the boundaries of branches?

On Friday 04 June 2010 18:53:53 W. Trevor King wrote:
> 
> On Fri, Jun 04, 2010 at 04:27:31PM +0200, Ronny Pfannschmidt wrote:
> > but i want to have some kind of central access to the bug database
> > for end-users and maintainers
> 
> If someone can give a clear description of the desired interface, one
> of us will code it up sooner or later.  Suggested interface:
> 
>   be list -r repo1,repo2,repo3,repo4
> which is not currently implemented, but would be pretty easy.

this can be done even without any change to BE itself, just using some shell 
code (ok, changing directly BE is much better  )

The same for 'be html' 
I don't know for CFBE or a GUI

bye
Gianluca