SRU shift report: 2020-09-23

Robie Basak robie.basak at
Fri Sep 25 14:11:34 UTC 2020

Hi Thomas,

On Thu, Sep 24, 2020 at 08:02:23AM -0400, Thomas Ward wrote:
> Original SRU 'justification' written in the bug[1] states the regression
> risk is "There should be none."  As you stated elsewhere, "none" is not
> a valid risk justification.
> Further, they're waiting for this to be done in Debian as well (see [2])
> so it does indeed need a wait on this going forward because it needs to
> be fixed in another spot - that blocks SRU processing, but if we're
> going to be nitpicky as we should be, you should probably "block" also
> on the lack of a justification - as "there should be none" is not really
> a valid potential analysis.


For new contributors I try to be more slack in what I accept. Though not
in what I land - I'll spend the time taking the role of the developer,
fixing up the SRU documentation and the upload as necessary to meet our
standards first. This is in the hope that they'll contribute again and
learn our processes over time.

Of course SRU team members are all capable core devs and so we can
always just take over the work and fix up whatever we think necessary.
But for regular uploaders, what pains me about doing this is that it
seems like it wastes time - it'd be quicker overall for the uploader to
do it since they already know all the details, rather than me having to
infer it all first. It's so much quicker and easier to review and
understand things when the person who already knows all the details has
written it down. And if I want something changed substantially, then I
also want an ack from the uploader for my proposal to make sure it still
meets their expectations and needs, and also that the final accepted
upload has had a proper review from both the uploader and the SRU
reviewer. And so that necessiates more round trips.

When I first joined the SRU team and asked about this, I remember a
colleague pointing out that as there are far fewer SRU team members than
uploaders, it makes much more sense for the uploaders to do the parts
that both groups can do, and keep the SRU team focused on reviews rather
than forever fixing things up.

In practice I try to find some kind of balance. If it's a trivial
oversight I'm happy to fix things up myself[1].

I write this to try and explain my expectations better to everyone.
Nothing above is aimed at you specifically Thomas - IIRC your SRU
uploads are exemplary :)


[1] As an aside, when fixing up others' uploads I always find it
difficult to balance the need to credit the uploader appropriately
against attributing my unagreed changes to their name in the changelog
entry. What if I want to completely reword the changelog text, for
example? Should I then seek their approval but cost the review another
feedback cycle? But anyway, I try my best to get the balance right.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <>

More information about the ubuntu-devel mailing list