The Application of Colin King for PPU - Q&A and Voting Thread
Colin Ian King
colin.king at canonical.com
Wed May 24 21:33:49 UTC 2017
On 24/05/17 08:54, Lukasz Zemczak wrote:
> Hey Colin!
> On 24 May 2017 at 00:09, Colin Ian King <colin.king at canonical.com> wrote:
>> One specific reason that comes to mind is that it fails the ADT testing.
>> I'd immediately check the status at
>> and investigate that first.
> That's the main reason indeed! But are there any others? Let's say,
> you pushed a new package to the development series, all autopkgtests
> succeed, no archive freeze is in place - but your package still
> doesn't automatically migrate. What could be wrong? Where should you
> look for some answers?
One of the more likely reasons why it fails to migrate is because of the
package's dependencies. For example, it may depend on a particular
version of a library and until that version is also available. We may
have a cascade of dependencies, and so until all the dependencies are
fully available then the uploaded package won't go into the release
pocket until the the dependencies are available.
I'd look at
to double check for errors such as this.
>> 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.
> Excellent. Just needed to know if you were the one preparing the SRU
> paperwork or not. No further questions here.
>>> 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:
>>>> 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
More information about the Devel-permissions