Wednesday 10 April 2019

Re: Delegating hinting for autopkg failures to core developers and MOTU

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEXHq+og+GMEWcyMi14n8s+EWML6QFAlyuYL8ACgkQ4n8s+EWM
L6Q5oBAAsTDyUQOiYWP5ut44opkvCYPY2chpD0ll5euatblIbqYiz2604s+9rwK9
oWMGq8Q3PyT7NDy+4Uy6xdv5yKeGaG4fmil6kPvpaILRq6vnZKyeqhoRYRV7YiWu
M7JoV/x0db+E2h8V5LqiE0u0YRkiiuMs/0v0hs6UrtQElGGgTZMjdMbHFvvzLcYT
e9VRzBN0l7QcUqrWyqnAv3qmB9AF12G8Xqg117YUxzjhYjyBJk+0jLybdWzkG2Vm
vd5vUeD+OGBFctLZSms97GaECDmT7y//aodkgdDyDqDiVQRdqu0u49RIdTRJltPi
9fP9es6f6RvVgiWanEMtsoxIioy5+GfDBXsjeJPUhK6uWpJ2RKEipClrQtn/b0d9
cv/z1l5ABGQaV/GWHwnWn/EvXNOx6Q3zQznDd8JgThsxpxPUSu7Bd8BDgLXf6n4J
rwvrMqMNRp7gzGyG0Z/U8fJ67zuiXB5gNWO41k03cOuPrQ9vg7SCT5dmONUpD8dn
qdh+9Q5lYAKMPa97dBveBp/Q4XtB09PUIh7Fio2kg7iGdXWKxoHQN3ChJYfu/RXc
s14qpTvmV5SD7+t3H/LTUp+hjm0LbdBonwLw9W9yqNIg6sJUoLgCaVZbKvVd8vNs
X1TsV/juX2xJG4pODLO7Gw0TJJSgyZbSvoGbGWOgbTkGOLVHe2o=
=aD1O
-----END PGP SIGNATURE-----
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@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4