The Application of Colin King for PPU - Q&A and Voting Thread

[Colin Ian King]

Hi Lukasz

On 23/05/17 18:58, Lukasz Zemczak wrote:
> Hello Colin!
> 
> Let me start off with a few quick and standard questions myself. I'm
> sure those will be easy - just making sure you were looking after
> those parts before.
> 
> 1. After getting PPU rights for the packages I want to make sure you
> would be able to follow them to the end after the upload. What could
> go wrong that could cause a package to get stuck in -proposed and not
> automatically migrate to the release pocket? Where would you look for
> for answers?

One specific reason that comes to mind is that it fails the ADT testing.
I'd immediately check the status at
http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
and investigate that first.

> 
> 2. An SRU-related question: when publishing an update to a stable
> supported series, what information should you provide on the bug
> (especially regarding regression potential)?

I'm very familiar with this as I work on many SRU bugs for the Ubuntu
kernel and I want to avoid any form of kernel breakage/regressions. In
fact I was reviewing a patch today in the kernel team mailing list and
had to remind the person sending the patch of the due process (see
https://lists.ubuntu.com/archives/kernel-team/2017-May/084309.html )

The required information is as follows:

a) [Impact] A clear explanation of the bug and a good justification for
the fix.  It is preferable to also describe how the SRU will
specifically fix the bug.

b) [Test Case]. A set of clear instructions on how to reproduce the bug.
These need provide enough information for a person who as no prior
knowledge about the issue to trip the bug and to also check if the bug
has been fixed.

c) [Regression Potential] A coherent overview of how the SRU fix could
possibly occur and how they would be observed. Each potential regression
should explicitly state the risk of the regression and the likely impact.

For larger upstream releases for a SRU, this requires more detail since
the change set is larger, so references to the release QA process, test
cases and relevant test documentation is preferred way of showing if
suitable verification has been performed.

Basically, one needs demonstrate that one has carefully examined the
multitude of ways that the fix could effect the system and list the
risks associated with these.  The more information the better. No
information shows that one has clearly not given any thought to this and
this is a good reason for having the SRU rejected.

Note: The information to provide is details at length in the
https://wiki.ubuntu.com/StableReleaseUpdates wiki page.

Colin.

> 
> Thanks.
> 
> 
> On 23 May 2017 at 10:14, Lukasz Zemczak <lukasz.zemczak at canonical.com> wrote:
>> Hello everyone!
>>
>> On yesterday's DMB meeting we have decided to handle Colin King's PPU
>> application remotely through e-mail. I am starting this thread to
>> begin the review process and then proceed with voting.
>>
>> The application in mention:
>> https://wiki.ubuntu.com/ColinKing/DeveloperZFSandSPL
>>
>> In short: Colin is applying for PPU rights for zfsutils-linux and spl-linux.
>>
>> I would like us to start with questions and after a day or two we
>> begin the voting process.
>> Please be sure to ask questions as soon as possible, since for this
>> application not to go on forever I will not be waiting indefinitely
>> for everyone to get the required feedback from our applicant.
>>
>> Best regards,
>>
>> --
>> Łukasz 'sil2100' Zemczak
>>  Foundations Team
>>  lukasz.zemczak at canonical.com
>>  www.canonical.com
> 
> 
>