launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Wed, Aug 26, 2009 at 7:24 AM, Jamu Kakar<jkakar@xxxxxxxx> wrote:
> 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.
>

I've heard very similar thoughts from people in the Twisted community,
who follow a similar practice.

I could have _sworn_ I filed a bug about it. Bug 297872 (Tighter
relationship between bug-branch links and merge proposals) is close,
but not quite it.

Ahh, bug 343410 (Detailed merged revision page) is the one I was
thinking of, except it's also not quite what you want.

I'd really appreciate it if you could look at those bugs and either
comment or file other ones, so that we can better track this. If you
can't figure out what bugs to file, let's keep talking here.

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

Good point! Could you please file this as a bug too?

jml