"Server" package merges and duplicated effort

[Louis Bouchard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

Le 14/01/2016 13:36, Robie Basak a écrit :
> 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.
> 
> Robie
> 

+1 : I've seen most of these situation happen to me.

Working toward Core Dev means learning about merges, transitions, etc which
all require sponsorship.

There was a time where many core devs would meet every six months which helped
coordinate the work. Now ties are much more slack and depending on who you
talk, you get different suggestions.

Though I don't think why working on a blueprint assignment for merges negate
the fact that one should follow the merge documentation[1]. At least that is
what I tried to do recently[2] with the nut merge.

If one has to create a bug before starting a merge effort, it is trivial to
verify if the merge bug exists already.

Maybe I'm wrong but unless told otherwise, I'm planning to continue doing
this. I saw some people adding the merge bug number to the blueprint, maybe
this could be added to the procedure ?

MTCW,

...Louis


[1] https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[2] https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1522346


- -- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer                       Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWl6T4AAoJEFZStL2qfwOtqfoP/2PKtKEfMe1wyj83R7prIYAo
VkoSREdzkp+RpIY3d8Xar4msSMcqzoIEBsjcbbQjIR6YK0UBacRi9uzWWWcC64HW
BIvM/di8xJpoe6hDXl1sjW3yQhqEIHVRvW7Bwjr10wDxxG0Oh9R/erX7NQrlEH/u
uazuqgCaBac3sZqyT9CeCPdO+Hqy5illEJJiSt15ivFyDbQD33QOPW/pOlGt9UzJ
R9FeqxeriqkR+nQlCuP1WtW1QxgUBCl2zIeCtKb0ZDgvDzR6dkhiu/fuT7MlI6fN
bU9PDvV6fxHJ1Q40p6KvIM2lDwvivLk2d5ACYcmhE8vJKOaI6gh+65pnrFBf6etG
j9qR7ZrOoqX/i503LfTS3FlbOperiaM/jh3tcPtENDXAxSR/Xm+ZCn6XKn2YmoUt
l/nBvCkzdV/zAoF82VKRVXMvapHoJcxUyHaF7bFG1c3cLIkSmaST7OEF07Vdwtdb
CZjCAxMu9ZntTk4mSa/29d+pstx0T8EgI44H+hd31KdPUDwe5Vh86DYkViphNR3N
Z/zVveirTUQ01RZHY9KLEKeChuiGbfZvMSvVVIKvwg4f2XyQ0zsO5pyAJ97IY7/g
84o+hPnys/RrZ9v0gpAGroZ9OZhb+RvkjBJC8KdAdgylS2KJnXMsj1zeeHcGFSye
aLzBzPa5153cyvAFlzdk
=AHuw
-----END PGP SIGNATURE-----