Ubuntu MOTU Application

[Łukasz 'sil2100' Zemczak]

Hi!

Thank you for handling my application through e-mail! Let me try
answering the outlined questions below - I apologize if some answers
might seem a bit chaotic though.

On 13.05.2014 15:23, Iain Lane wrote:
> Hi Łukasz,
> 
> On Tue, Apr 29, 2014 at 03:23:21PM +0200, Łukasz 'sil2100' Zemczak wrote:
>> Hello,
>>
>> I would like to apply for MOTU membership.
>> My application can be found here:
>>
>> https://wiki.ubuntu.com/LukaszZemczak/DeveloperApplication-MOTU
> 
> As we've discussed with you in private, we think it'd be easier if we
> handle this application on email. It's the same as on IRC: questions and
> answers followed by voting.
> 
> Here's some initial questions. Others will follow up later.
> 
>  - What's the goal of your application? What packages / areas are you
>    most intested in?

My main goal is to put my packaging skills to use, helping out
maintaining and sponsoring packages - basically taking off some load
from other developers. We are getting more and more packages into the
archive.
Most of the packages I am involved with personally are located in
universe, by becoming a MOTU would make both my and all sponsors lives
easier ;)

I am most interested, of course, in the universe packages we handle
through CI Train. But I do not intend to only focus on those, but help
out wherever I can.

>  - Your work involves uploading packages through the CI train a lot. Are
>    you relying on the experience you've gained here for this
>    application? If so, can you outline how it's been helpful?

I wouldn't say I'm relying on the experience gained through CI train
usage, but it is a fact that it also helped me gain additional
knowledge. I had experience with releasing packages to the archive in
normal means in the past, preparing releases of unity, compiz and others
with the help of didrocks. I also prepared the packaging for a few
packages in the universe as well, getting those uploaded by various
sponsors.
But CI train (and the earlier daily-release cu2d) usage helps out
understanding things better. Whenever there is a packaging change in a
new release pending, I am performing a 'review' of the packaging before
sending it to a core-dev for a final +1/-1. This teaches a lot about
resolving common problems, such as main-universe mismatches, missing
soname changes, wrongly bumped dependencies and such. Not to mention
whenever a new package is to be released through CI train, we are also
responsible for doing a preliminary review of the packaging, to make
sure it fits the standards of our archives (+ some of our own nit-picks).

This way, because of cu2d and CI Train, most of my time spent on
Ubuntu-related development recently was related to packaging :)

>  - There's sometimes a certain amount of tension between the CI train
>    and other Ubuntu teams. Can you think of any ways this can be
>    alleviated? Some examples I'm thinking of
>    + When an Ubuntu developer directly uploads a package under CI there
>      is often quite a bit of back and forth required to get the VCS back
>      in sync. This even happens for no-change rebuilds!
>    + When the archive is frozen close to release, or after release for
>      SRUs, the CI train stalls. For these reasons members of the CI
>      landing team often have to ask for expedited treatment of their
>      uploads from the release or SRU teams, creating tension. I see two
>      technical factors at play here, and a social one:
>      * 'silos' in the CI train are a limited resource and per policy
>        (and a technical limitation in Launchpad) they are not released
>        until the upload is in the release pocket
>      * having one upload in CI train locks that project out for further
>        releases until the existing one is already finished
>      * upstream developers expect to see their uploads in Ubuntu more or
>        less immediately

Sadly, some tension is inevitable I suppose...
Basically, whenever some direct upload is made in the middle of the
component being prepared for release in a silo, there's always the risk
of the uploaded change causing an issue if combined with the pending
changes. Whenever something is put in a silo, we enforce the person
requesting the change to test the newly prepared package before
publishing - so basically, if a direct upload is made, the testing has
to be re-done to make sure nothing is broken once again.

There are some improvements that could be done here of course. We could
for instance make the CI Train infrastructure not only to inform the
lander whenever such an upload is made but also, I guess, even creating
a bzr branch automatically with the changes in the archive (and maybe
even proposing it as a merge). Information about the merge request would
be sent out to the lander and the landing team - if it's a no-change
rebuild, then the lander would know he can simply add that merge (to
have the changelog entry present), rebuild and publish once again
without any worry. If there were changes, he can rebuild with those
merged in and retry testing again.
This might lower the tension in this case, as the direct uploader will
no longer be blamed for not merging his/her change to trunk (as CI train
will handle doing that for him), while the landers will also be more
happy as they would have less on their mind. Implementing that is
possible, but we need to remember that CI Train is still just a
'temporary' solution in our road to CI Airlines ;) So there's also a
question of how much we should invest in enhancing this infrastructure,
considering that it will not be used for long.

In the second case, well... there are some things we could improve here
as well. The biggest problem is as you mentioned, that silos are limited
in number. This e-mail might become too long to read if I start pouring
all my ideas regarding that though, but I am open for a discussion in a
different separate thread ;)

>  - (to get off the topic of the CI train :P) What do you think the main
>    aims of the MOTU team as a whole are?

In my understanding, the MOTU are an awesome group of individuals that
add, manage and maintain packages in universe and multiverse of Ubuntu.
The main aim is to have someone that could help out with sponsoring new
uploads of various packages, but also things like syncing changes both
ways to and from Debian when needed.
This doesn't only imply packaging, but also fixing bugs and FTBFS when
possible.

>  - MOTU's struggled with recruitment for a while now. Can you think of
>    any strategies we could undertake to try and recruit and maintain
>    more team members?

It's not easy to come up with any solid ideas here. I always think the
reasons for things like these are social-related. Maybe, to get more
possible candidates, the existence of MOTU could be made more explicit
to the users. I suppose some developers contributing to Ubuntu might not
even know of the existence of the MOTU. Maybe explicitly mentioning the
main teams and roles of those teams on the main Ubuntu webpage, or at
least on developer.ubuntu.com. Then people could have a better idea of
what to aim even!

Also, I noticed there aren't any MOTU meetings mentioned on the wiki
page. The last one is said to be from 2012.

> 
> Thanks,
> 

Thank you, and I hope I answered most of the questions in a satisfiable way.

Waiting for any further questions!

-- 
Łukasz 'sil2100' Zemczak
 lukasz.zemczak at canonical.com
 www.canonical.com
 www.ubuntu.com