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@ubuntu.com vorlon@debian.org
