Thursday, 14 January 2016

Re: "Server" package merges and duplicated effort

On Thu, Jan 14, 2016 at 12:36:18PM +0000, Robie Basak wrote:
> On Thu, Jan 14, 2016 at 01:16:20PM +0100, Martin Pitt wrote:
> > Wouldn't it be easier to add a comment to the package on the MoM page
> > to say "joedeveloper is working on that"? That "comment" column is
> > meant for that very purpose :-)

> I think part of the problem is that there are many different locks, and
> different people use different ones.

> * There's the MoM comment column as you say.

> * There's TIL. What does that mean, anyway? The last uploader, the last
> sponsor, do we skip minor and security uploads, do we only use the
> last person who merged? And what if the TIL person is offline or
> unavailable? I think different devs are doing different things here,
> too.

> * Merge bug assignment.

> * Blueprint work item assignment.

> I think this is more of a problem right now as we have many merges in
> flight. More than usual because a pile are being done by people without
> upload rights, so naturally the review process means that merges take
> much longer to complete.

> I also think it matters more where sponsorship is required. I remember
> how frustrating it was to get trumped while waiting for review.

> I'd be happy to pick any one lock method, if it is well-defined and
> there's consensus that that one is the One True Way.

My understanding of the existing lock algorithm is:

- If you are TIL, you have the (advisory) lock. Go ahead and do the work
if you are going to.
- If you are not TIL, talk to the TIL, who is always the person listed on (or If there are two people listed
(because sponsorship), ideally you should talk to both of them - it's not
obvious that one is more likely than the other to feel responsible for
merging the next version, so a collision is possible with either of them.
- Once the TIL has handed off the package to you, if the merge is going to
take any length of time (e.g. because of sponsorship), open a merge bug
and assign it to yourself to document your lock.
- If you see a merge bug that's lingering for a long time without progress,
and the package needs merged, talk to the owner/submitter about taking it

Does that sound right to you?

I would not expect a blueprint work item to be part of the lock mechanism.
Not all teams use blueprints these days, and blueprint work items are
invisible when approaching a package from the direction of Tracking work items within teams this way can make
sense, but please make sure that if you're taking a lock on a merge you do
so in the central MoM view.

Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer