I, Ike Panhc, already have the upload right for linux-armadaxp and linux-meta-armadaxp and request for upload right for other packages I maintain: linux-exynos5, linux-meta-exynos5, linux-keystone and linux-meta-keystone. Since these packages are all customized kernels for specific platform, and maintained by Canonical Hyperscale team, I propose that we make a new package set, Hyperscale, for these packages.

Who I am

I am member of the Canonical Hyperscale Team, who focus on hardware enablement and maintenance for kernel packages.

Why these packages

Canonical co-work with several CPU vendors to make sure that Ubuntu runs well on their platform and users are satisfied with hardware and software feature such as 10Gb ethernet or openstack. To fulfill those features, we need patches which do not be accepted for -generic kernel because introduces regression on other platform. That's why we need separate source packages only for specific platform.

My Ubuntu story

My involvement

I joined Canonical and started to contribute to Ubuntu and the mainline kernel 5 years ago. In the beginning, most of the bugs and projects I am involved in are laptop related, such as rfkill and hotkey function for specific laptop.

I start to involve hyperscale projects 2 years ago since Canonical worked with several SoC vendor. Since that, I start to develop and maintain the customized kernels for several platforms such as Marvell ArmadaXP, Samsung Exynos5 and TI keystone.

Examples of my work / Things I'm proud of

To maintain a kernel package in main, it is important to fetch the CVE fix from -generic kernel and also perform smoke test to make sure there is no regression introduced. Once after re-package linux-armadaxp, I found system can not reboot with new kernel when smoke test. Therefore I bisected patches and find out there is a patch from stable kernel which changes the shutdown/reboot state machine and that is the root cause. To revert that patch solve the problem and keep our promise of maintanence in main archive.

Ubuntu contribution

• linux-armadaxp in Precise
  • 3.2.0-1601.4, 3.2.0-1602.5, sponsored by Jani Monoses.
  • 3.2.0-1606.9, 3.2.0-1607.10, 3.2.0-1607.11, 3.2.0-1608.12, 3.2.0-1608.13, 3.2.0-1613.18, 3.2.0-1614.19, 3.2.0-1615.20, 3.2.0-1615.21, 3.2.0-1615.22, 3.2.0-1615.23, 3.2.0-1616.24, 3.2.0-1616.25, 3.2.0-1617.26, 3.2.0-1617.27, 3.2.0-1618.28, 3.2.0-1619.29, 3.2.0-1620.30, 3.2.0-1621.31, 3.2.0-1621.32, 3.2.0-1622.33, 3.2.0-1623.34, 3.2.0-1623.35, 3.2.0-1624.36, 3.2.0-1625.37, 3.2.0-1626.38, 3.2.0-1627.39, 3.2.0-1628.40, 3.2.0-1629.41, 3.2.0-1630.42, 3.2.0-1631.43, 3.2.0-1632.44, 3.2.0-1633.47, 3.2.0-1634.48, 3.2.0-1634.49, 3.2.0-1635.50, 3.2.0-1636.51, 3.2.0-1636.52, 3.2.0-1637.54.
• linux-armadaxp in Quantal
  • 3.5.0-1602.4, 3.5.0-1604.6, 3.5.0-1605.7, 3.5.0-1606.8, 3.5.0-1607.9, 3.5.0-1608.10, 3.5.0-1609.11, 3.5.0-1609.12, 3.5.0-1609.13, 3.5.0-1610.14, 3.5.0-1610.15, 3.5.0-1611.16, 3.5.0-1611.17, 3.5.0-1612.18, 3.5.0-1612.19, 3.5.0-1613.20, 3.5.0-1614.21, 3.5.0-1615.22, 3.5.0-1616.23, 3.5.0-1616.24, 3.5.0-1617.25, 3.5.0-1618.26, 3.5.0-1619.27, 3.5.0-1620.28, 3.5.0-1621.29, 3.5.0-1622.30, 3.5.0-1623.32, 3.5.0-1624.33, 3.5.0-1625.34, 3.5.0-1626.35, 3.5.0-1627.36, 3.5.0-1628.37, 3.5.0-1629.38, 3.5.0-1630.39, 3.5.0-1631.41, 3.5.0-1631.42.
• linux-exynos5 in Saucy
  • 3.11.0-204.12, 3.11.0-205.13 sponsored by Adam Conrad.
• linux-exynos5 in Trusty
  • 3.13.0-3.3 sponsored by Brad Figg.
  • 3.13.0-5.5 sponsored by Adam Conrad.
• linux-keystone in Trusty
  • 3.13.0-6.9 sponsored by Andy Whitcroft.
  • 3.13.0-7.10, 3.13.0-7.11, 3.13.0-8.12, 3.13.0-9.14 sponsored by Adam Conrad.
  • 3.13.0-10.15 sponsored by Chris J Arges.

Areas of work

• I focus on kernel developing and maintenance for a specific platform. To make sure the kernel feature such as LXC, KVM, apparmor has been enabled to support all the userspace application. Also cowork with kernel team to fetch security fix from master kernel branch. Perform kernel smoke test on each upload to make sure there is no functional regression for each developing and maintaining cycle.

Things I could do better

• I depend on kernel team for debian packaging and other policy which I do not think its reasonable for a long term. To read debian handbook and find out what material provided by kernel necessary for key feature of Ubuntu is important for me for future developing and keep me out of stupid mistake.

Plans for the future

General

• Continue to perform kernel packaging and testing, including automatic kernel functional testing and performance testing to prevent not only the function regression but also performance regression.
• Kernel is important, but not everything for a distribution or a system. Since I've known how to develop and maintain kernel packages, its will be good for me to understand those application which directly access kernel functions such as openstack, kvm. The first step to understand those is to fix bug or develop new function and provide the patches for maintainer.

Comments

If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.

Endorsements

As a sponsor, just copy the template below, fill it out and add it to this section.

TEMPLATE

== <SPONSORS NAME> ==
=== General feedback ===
## Please fill us in on your shared experience. (How many packages did you sponsor? How would you judge the quality? How would you describe the improvements? Do you trust the applicant?)
=== Specific Experiences of working together ===
''Please add good examples of your work together, but also cases that could have handled better.''
## Full list of sponsored packages can be generated here:
## http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?
=== Areas of Improvement ===