Some questions on MOTU.

[Scott Kitterman]

On Friday, July 20, 2012 06:15:09 PM John Kim wrote:
> I've been studying the packaging guide for a while now, and I want to know
> how you guys work.  Packaging seems like a hybrid of bug fixing and
> uploading content to branches.

It's actually uploading content to the Ubuntu package archive.  Branches are a 
way to stage and track the changes.  Some people find them more useful than 
others.

> 1. Is it recommended to run the development release alongside the stable
> one?  If so, what is used to run the development release?

It's helpful, but not essential.  Some people have a second computer or run it 
in a VM.

> 2. What does MOTU do for the development release?

Generally MOTU care for the packages that are not part of the standard set of 
packages installed by one of the standard flavors produced in the Ubuntu 
project (like Ubuntu [desktop], Ubuntu Server, Kubuntu, Xubuntu, etc.).

There are a wide variety of potential things to do.  Identifying and fixing 
bugs, submitting patches back upstream (to Debian in some cases or the package 
upstream), identifying obsolete packages that are candidates for removal, 
tracking library transitions and figuring out how to port packages to newer 
versions of libraries they use, updating packages to newer versions, etc.  The 
list is long and there's plenty to do.  It's the same thing Ubuntu desktop 
developers do, just with a focus on a different set of packages (nothing says 
you're limited though - Ubuntu doesn't have dedicated maintainers for 
packages, so anyone can work on most anything).

The primary difference between a MOTU and someone who's not yet a MOTU is that 
MOTU have been granted the privilege of uploading packages directly to the 
Ubuntu archive.  It's a big responsibility to release software that might end 
up running on millions of desktops.

> 3. How could starters decide what to package?  Checking out harvest.com and
> hanging out in IRC, I can't tell what bitesize bug is manageable for the
> novice packager.  For instance, packages with fixed typos rarely ever get
> uploaded. So is looking at a bug in launchpad, which feels daunting.

If you aren't a self starter, you won't get far.  The single most important 
thing is to find something you're interested in.  It can be a technology area, 
a class of problems, most anything.  When I first started I was interested in 
getting packages to support a new technology into Ubuntu and in fixing 
installation/upgrade failures I was seeing on the systems I was using.  Figure 
out what your itch is and scratch it.

Once you've got a handle on that, then you'll have a better idea where to 
start and how to dig in.  Hanging out on IRC and asking questions is always a 
good idea.

> 4. What should novice developers start out with?

See above.  Start out with what motivates you (although new packages from 
scratch is NOT the place to start - you have to know something about all 
aspects of packaging to do that).

> 5.  I'm sure that mastering the package guide alone isn't enough to take
> the interested packager into the real deal. What are some great resources
> other than the packaging guide to use to learn more about packaging?
> 
> I have yet to dive in more deeply into the Debian guides, but in the
> meantime, I just want to clear up some ideas. Thanks.

Don't worry about mastering anything.  Figure out what you want to accomplish 
and then learn just the bits that are needed for that.  You'll learn the rest 
as you solve other problems.

Scott K