Core Developer application for William Grant

[William Grant]

Hi, thanks for starting this off!

On 20/01/14 22:05, Stefano Rivera wrote:
> Hi Iain (2014.01.12_23:44:11_+0200)
>> I'll leave this in the hope that someone else can begin the application
>> properly with questions. It should be fairly straightforward. :-)
> 
> Let's get the ball rolling. Yeah, I don't think this will be hard
> 
> What freezes do you need to be aware of when uploading packages? Which
> packages do they affect?

FeatureFreeze, FinalFreeze and the soft image freezes are the main ones
that tend to affect my work. FeatureFreeze affects everything, while
FinalFreeze (until the very end) and the soft image freezes now just
impact those packages that are in images for that release, a set which
is easily determined by combining ubuntu-devel-announce and the
seeded-in-ubuntu tool.

> Are you subscribed to ubuntu-devel-announce.

For about eight years now.

> Soo. You're involved in the ppc64el bringup. What's the easiest way to
> debug failures in that port, without access to hardware?

I'm not sure of a good all-round answer here just yet.

By far the most common types of failures are fixed by an autoreconf to
update config.{sub,guess} and libtool.m4. Confirming that a build on any
architecture updates those files is usually sufficient evidence to throw
it at the archive and hope it builds. Most other failures aren't
endian-specific, so they can be effectively debugged in a Debian ppc64
image in qemu.

If a failure *is* endian-specific, there's a set of patches heading
upstream that should make qemu work with our little-endian kernels, but
I don't think they're in the archive qemu yet. So unless you're
particularly masochistic it's probably best to throw it at someone with
access to hardware, for now.

> I quote from your application:
>> Certain important software needs to go through Jenkins-based CI
>> systems, and uploading changes as if they were normal packages can
>> block their normal development processes.
> 
> Wasn't that not supposed to happen? I recall the argument for this CI
> process was clear that it wouldn't block any core-dev from doing any
> normal upload.

I'm not completely sure of the details, but it was a significant issue
very late in saucy. Manual uploads work fine, but IIRC they cause the
autolander to stop until someone manually integrates the direct upload.
Temporarily halting automation obviously isn't ideal when there's rapid
iteration going on to get a good image.

>> The wildly differing implementations of version control and continuous
>> integration around the archive make it awkward to efficiently work
>> across a varied set of packages.
> 
> So, how do we solve this? :)

Um. Good question. In my ideal world we'd have working version control
for the entire archive, with all changes going in as merge proposals,
then through tests, then into the archive. But that's hard.

UDD fails on the first point today, as it can't import everything
reliably. And, due to the nature of many of our good relationships with
Debian, it's probably always going to be better to maintain some
packages in a VCS on the Debian side of things. And you have to be
careful when putting slow tests into the critical path, as the cost of
delays can quickly outweigh the benefits. Devising an effective, unified
solution that doesn't hinder anyone is going to require an awful lot of
thought from a large variety of people.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/devel-permissions/attachments/20140120/089534fa/attachment.pgp>