Delegating hinting for autopkg failures to core developers and MOTU

[Simon Quigley]

Hello,

On 4/10/19 12:20 AM, Matthias Klose wrote:
> Please can we delegate the hinting for autopkg test failures to core developers
> and MOTU?
> 
> When ignoring an autopkg test failure, you usually have a reason to do so.  As a
> core developer you already can work around autopkg test failures with uploading
> a work-around in a new package version, both for main and universe packages.
> The disadvantage is a longer turn-around, re-triggered autopkg tests,
> introducing a delta which has to be maintained.  MOTU could be limited to only
> hint failures for universe packages.
> 
> The current limitation of autopkg related hints being done by the release team
> seems to be a technical limitation, because other hints are done by the release
> team only.  Of course there should be informal restrictions for hinting during
> archive freezes, release freezes.

I generally disagree with this. The Release Team is ultimately
responsible for ensuring the archive is releasable; if we let every
Ubuntu Developer hint packages, the Release Team would ultimately be
giving up enforcement of what is supposed to be a hard freeze at some
points in the cycle, and what are generally supposed to be clear release
goals.

If the role of the Release Team were to be dissolved and the power were
to be given to individual developers, I doubt we would be able to keep a
stable release pocket, which hurts both our users and our customers. If
I believe a package should be hinted, I always discuss it on
#ubuntu-release; sure, sometimes they don't have to follow up with me
about it and the Release Team just does it, but I'm not perfect, and
productive discussion out in the open about hinting a package not only
fosters understanding for prospective developers, but it allows for a
higher-quality release.

I am aware of a handful of Ubuntu Developers who regularly either come
to me personally or to #ubuntu-release because they don't quite
understand the ramifications behind hinting something or are lost in
proposed-migration. From a DMB perspective, while we are working towards
setting forth clearer expectations, we don't always thoroughly verify
that a candidate knows top-to-bottom how proposed-migration works. I
personally have faith that the vast majority of Ubuntu Developers know
general Ubuntu processes and packaging, but I don't have faith that a
majority can walk through p-m past simple cases.

Where I would tend to agree with your general point is, we should have a
clearer process on becoming a member of the Release Team (and a more
diverse set of people on the team). If an Ubuntu Core Developer very
evidently knows proposed-migration and the ramifications of hinting
packages, they should be empowered to make rational decisions rather
than having to nag the Release Team all the time. To be clear, I'm not
suggesting the Release Team begins adding people left and right, and the
candidates should be high quality, but the Release Team has 7 members at
the moment; one of which is a community member, the rest work for
Canonical and (last time I checked) either are members of Canonical
Foundations or once were, with the most recent two members being added
in 2016 and 2017 (the rest are in the 2006-2012 range).

Thoughts on this, especially from the Release Team, would be appreciated.

Thanks,
-- 
Simon Quigley
tsimonq2 at ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20190410/78225af1/attachment.sig>