"Server" package merges and duplicated effort

[Steve Langasek]

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
   https://merges.ubuntu.com/main.html (or
   https://merges.ubuntu.com/universe.html).  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
   over.

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
merges.ubuntu.com.  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.

Thanks,
-- 
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                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20160114/c7cf667e/attachment.pgp>