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 [cjwat...@ubuntu.com] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
