On Fri, Sep 25, 2020 at 10:11 AM Robie Basak wrote:
>
> 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.
>
> Agreed.
>
> 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,
that's true; of the official list of members:
https://launchpad.net/~ubuntu-sru/+members
Only 6 are part of the SRU Vanguard schedule:
https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
And all 6 of those members are directly involved in the development
release cycle, so in the month (or two...) leading up to each release,
they (understandably) are very busy and the SRU upload queue reviews
get less attention. This has been frustrating for SRU uploaders (like
me) in the past.
And of course, 6 reviewers is a small number, especially when they all
have very demanding work besides reviewing SRU uploads. Maybe it's
time to increase the number of SRU team members? It would be
especially helpful if there was at least 1 SRU team member that wasn't
directly involved in the development cycle. That would reduce the
workload on the other SRU members during development cycle "crunch
time", and improve SRU review delays, which can be important since
stable releases need to continue getting bugfixes even during
development release months.
> 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 :)
>
> Robie
>
> [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.
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
