Jump start help needed.

[Colin Watson]

On Sun, Aug 23, 2015 at 08:49:42AM +0530, Vishnu Vivekanand wrote:
> a. The kind of programming I have done is that I am given access to a
> code base repository from where I download the entire codebase. Once I
> am assigned a bug I look into the code file that has the highest
> likelihood of being the home of that bug and once I have ascertained
> the same, I go ahead and correct/fix the code/bug.

This transfers well to what's called "upstream development": working on
a single part of the system in conjunction with its primary maintainers,
who occasionally make releases that then flow "downstream" to
distributions such as Ubuntu.

It does not necessarily transfer well to development of a distribution,
where the key point is integration of many packages into a coherent
whole.  Of course some of the same skills apply, but people from a
single-code-base background tend to find that they have to become much
better at quickly finding and navigating unfamiliar code bases.

> b. As far as what I have seen here, I need to download
> packages/tarballs, then install them. I have even went through
> tutorials of modifying code files using nano/vi/gedit editors, learnt
> to update changelogs, package/unpackage changes, create binary files
> (.deb).

That sort of thing is certainly important: it's bread-and-butter
development routine.

> I have also learnt the process of development in Ubuntu viz., take up
> bugs from Harvest --> find out if they have been already fixed by
> debian/future releases of Ubuntu or if someone else is already working
> on it --> if not, fix the bug --> update changelog, create package and
> request any Ubuntu Member to sponsor the fix.

I wouldn't call Harvest part of "the" process - it's one tool that may
be useful for some people to find bugs to work on, and if it works well
for you then great, but don't get hung up on it being the place to
expect to find everything.

Also, only people with upload access (Ubuntu developers) can sponsor
fixes, not the wider group of Ubuntu members.

> Now my questions here are
> 
> 	1. Is it wise to look for the entire code base and browse
> 	through all code files to understand the landscape of what I am
> 	getting into?

The entire code base for Ubuntu is ENORMOUS.  I don't think that
approach will tell you very much.  If you're talking about individual
packages, perhaps, although it's not a very efficient approach in
general if you plan to work on more than a very small number of
packages: it's better to hone the skill of finding the parts you need
without having to browse through everything.  It may be a useful
approach in the very early stages when you're still trying to get the
hang of how source packages tend to be laid out.

> 	2. Once I have a bug assigned to me, how do I go about
> 	identifying the exact location of fix?

Don't expect anyone to "manage" you and assign you bugs: that's not how
it works, unless you're a paid developer and thus somebody is actually
employed to tell you what to do.  (Even then, paid developers don't
usually need to have somebody micromanage every bug they choose to work
on.)

As for the main body of your question, you're asking how to perform a
fundamentally skilled and creative task which varies substantially
depending on the details of the bug, so there's no short answer.  In no
particular order, strategies include:

 * searching for things such as error messages in the code and guessing
   from there
 * using language-appropriate debugging tools to debug directly via
   tracebacks etc.
 * using static analysis tools (compilers with warnings turned all the
   way up to 11, things like cppcheck, etc.) to find
   mechanically-analysable problems that might contribute to the bug
 * using instrumentation frameworks (e.g. valgrind) to run code in an
   environment that can help track down problems where the cause is
   distant from the symptom
 * building unit tests that exhibit the bug you're trying to track down
   so that you don't have to run the full program to trigger it and so
   that you can help ensure that it doesn't come back after being fixed
 * investigating other bug reports on a similar subject, possibly in
   upstream bug trackers or other distributions
 * plain old experience of diagnosing many similar bugs

Lots of packages are relatively easy to start work on given an
appropriate base skill set (general familiarity with Ubuntu development,
experience in the implementation language(s) in question, etc.).  Some
are very specialised and it may be better to diagnose the bug as
accurately as you can and hand over to an expert.  Collaboration is an
important skill for Ubuntu developers too: we cannot work in glorious
isolation.

> 	3. Is there one central package that I need to download and
> 	lookup files/directories within it for possible location(s) of
> 	fix?

No.  Ubuntu is a distribution: it is assembled out of many packages,
some of which (e.g. most of the Unity UI, various package management
tools, etc.) were developed as part of Ubuntu from the beginning, but
most of which are primarily maintained elsewhere.  The latter category
is either packaged by our parent distribution, Debian, and flows down to
us from there (possibly with Ubuntu-specific modifications) or packaged
directly for Ubuntu.

Understanding this is useful both in terms of finding the communities
best placed to track down any particular bug, and in terms of finding
the correct place to send fixes as well as simply getting them into
Ubuntu: if a bug is in code that originated somewhere else, it is the
proper thing to do to contribute fixes back to the originator so that
users of systems other than Ubuntu can also benefit, and so that they
can be reviewed by experts.

But all this means that there is very definitely no single code base for
Ubuntu.  You will need to become experienced at identifying the package
containing a bug.  For instance, you might start by using "dpkg -S" to
look up the package containing a given file on your computer, starting
there, and if investigation reveals that the problem is actually in some
library that it uses then recursing into that.

> 	4. What is the Ubuntu culture of code development?
> 		a. Do they browse code files in the Ubuntu terminal and
> 		fix the bugs there using nano/vi?, or
> 		b. Do they use an Integrated Development Environment
> 		(IDE) like eclipse for code development?

Most developers I know use vim or emacs, both of which are very powerful
editors with many IDE-like features while still focusing on being
outstanding text editors.  But Ubuntu development isn't a homogeneous
culture so I'm sure you'll find different practices.  One thing to bear
in mind is that it matters greatly whether you're focusing on a small
number of large packages or trying to do something like polish and
consistency work across a broad swathe of Ubuntu; in the former case one
can afford to optimise one's workflow heavily for special cases, whereas
in the latter case the important thing is to have as little
unfamiliar-project overhead as possible.

Regards,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]