[RFC] Bugtracker workflow

[Robert Collins]

On Thu, 2006-08-17 at 11:23 -0400, Brad Bollenbach wrote:
> On 17-Aug-06, at 2:37 AM, Robert Collins wrote:
> 
> > On Tue, 2006-08-15 at 17:45 -0300, Christian Robottom Reis wrote:
> >>
> >> Note that the URL may not be +bugs to make it clear that this page
> >> doesn't list bugs that are /present/ in that series, but bugs that we
> >> /intend to fix/ in that series. That distinction is important --
> >> targeting a fix to a series is not the same as saying that  
> >> releases in
> >> that series are affected by that bug.
> >
> > I think it would be very nice for users to be able to look at 0.9, see
> > there is a bug present in it, and that its fixed in 0.10 and wont  
> > be in
> > 0.9. That would be lovely.
> 
> The release management UI can model this specific use case *if* 0.9  
> and 0.10 are different series.
> 
> You could explicitly reject the bug (Rejected is intended to split  
> off into something like Wontfix and Invalid) in the 0.9 series to say  
> you won't fix it there, and mark it fixed in the 0.10 series.
> 
> Will they be different series though?

They could be :).

I say that because at the moment there is no benefit to us to have them
as series, so we dont.

I can imagine the following being effective though:
- we have bzr.dev - 'trunk'.
- we open a new series when we do the release candidate for 0.10. (we
open a new branch when we do this anyway).

It raises a question about what to do with the bugs and specs we
targeted at 0.10 during the dev cycle for it. I guess we can retarget
them all by hand from bzr.dev/milestone-0.10 to the 0.10 release series.

Just saying 'well use a release series from the start' feels wrong to me
here, because a release-series is intended to represent a branch, and
there is no branch for 0.10 until the release candidate - or more
accurately, the branch for it shares the same physical space as bzr.dev
until the 0.10 branch is forked off of bzr.dev.

Perhaps making a release series could be allowed to do clone all the bug
state from an existing series to the new one to do this fork for us, or
perhaps the new one could be told to inherit the existing state [but not
new state].

I realise thats kind of speculative, but hopefully you see the point
about when the series should be made from a users perspective.

-Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060818/be5fc0cb/attachment.pgp