"Server" package merges and duplicated effort
louis.bouchard at canonical.com
Thu Jan 14 13:39:26 UTC 2016
-----BEGIN PGP SIGNED MESSAGE-----
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.
+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. At least that is
what I tried to do recently 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 ?
Software engineer, Cloud & Sustaining eng.
Ubuntu developer Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63 B9C4 8B3D 867C 823E 7A61
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the ubuntu-devel