launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

2009/8/26 Jamu Kakar <jkakar@xxxxxxxx>:
> Hi,
>
> On Tue, Aug 25, 2009 at 1:25 PM, Christian Robottom
> Reis<kiko@xxxxxxxxxxxxx> wrote:
>> On Fri, Aug 21, 2009 at 03:00:22PM -0300, Sidnei da Silva wrote:
>>> I'm wonder if you are surprised by Landscape being completely absent
>>> from that list *0.5 wink*.
>>>
>>> BTW, what's the status on our little requested features Tim?
>>
>> I am now that you mention it! What little features are you referring to?
>> Is there an easy query that lists what the blockers you considered would
>> be?
>
> [1]
>
> Every code-related task we do has a related bug report and is
> prioritized into a milestone.  If there is discussion about the
> issue, it happens as comments on the bug.  When a branch is
> available for review it is linked to the bug report and the 'review'
> tag is added.  The branch is 'In Progress' at this point.  We use
> the 'review' tag to create a review queue:
>
> https://bugs.edge.launchpad.net/<project>/+bugs?field.tag=review
>
> When a bug is ready to land we merge it, remove the 'review' tag and
> change the bug status to 'Fix Committed'.  It's very easy for us to
> look at a milestone listing and quickly see which bugs are not
> started (non-In Progress), which are being worked on and which are
> ready for final testing before release (Fix Committed).
>
> If we use merge proposals we'll split the above workflow between
> bugs and merge proposals and lose the integration we currently
> enjoy.  Being able to see how an issue unfolded from initial report
> through discussion and development to QA and final landing in a
> single place is important to us.

That's useful feedback.

We also have bugs for almost all changes, and some of them are targeted.

I think the split between "here's the bug" and "here's the fix" is
useful in some ways: the patch may not be interesting to users, and
bugs are not 1:1 with fixes.

However, I do think (and have filed bugs for)

 * the link should be much closer
 * you should be able to go in one click (or maybe even less) from the
bug to the review
 * the milestone page should tell you what needs to be reviewed to hit
the milestone
 * the review page should tell you about the bugs and milestones

I don't discount your fused-together case.  Maybe they should be
distinct but have some kind of combined view.  I'm not sure.

>
>
> [2]
>
> We require two people to provide +1's and no one to provide a -1
> before a branch can land.  Our reviews are comments on the bug
> report for the issue.  This mostly works well, but ambiguous
> situations arise, such when a +1 has been given by reviewer1 and
> then reviewer2 finds a major problem.  At this point the +1 from
> reviewer1 isn't really valid, they need to go back and re-review.
> We currently manage this by following the discussion.  When we don't
> know what the status is we talk to a reviewer directly to figure it
> out.
>
> Merge proposals don't really change this situation.  This isn't
> really a blocker as much as it's a non-adopter.

I think they do this ok, though more could be done here.  You can see,
in the listing, the individual votes and then the overall status, but
it's true that you will sometimes need to read the actual text to make
a decision.

I'd be interested to hear what you think about my rfc on handling
merges to multiple branches.

-- 
Martin <http://launchpad.net/~mbp/>