Debsources (http://sources.debian.net) is still under active development. We recently had a Gnome Outreachy intern, Jingjie Jiang, and we're about to work with 2 GSoC students, Cl ment Schreiner and Orestis Ioannou. I will present here the GitHub mirror we've set up, in order to allow external pull requests to be submitted, and to use the continous integration service provided by Travis-CI. GitHub and Travis-CI Debsources' source code is hosted on Debian's git servers, and from there is mirrored to GitHub. Every time a commit is pushed (to master or other branches) or a pull request is open, the test suite will be automatically run on Travis-CI, and the result (tests pass or don't) is displayed on GitHub. This allows us to quickly filter external contributions (when they are submitted on GitHub), and be sure everything works with our setup, before reviewing work. Travis-CI runs the tests on OpenVZ containers. The complete infrastructure was a bit challenging to setup, but as we now have a Docker recipe to quicly begin to hack on Debsources, most of the work could be done using the Dockerfile instructions. In average, a run on Travis-CI (which includes git cloning the code and test data, setup the server, and run the tests suite) takes 7 minutes, which is an ok amount of time to wait for before submitting a pull request, in my opinion. Bugs discovered in the process Setting up this continuous integration infrastructure made me discover a few bugs. Python magic does black magic Debsources runs fine on Debian (not surprisingly), but I got tricked by black magic when I tried to run it on Ubuntu (which is the OS run in Travis-CI's containers). We use the magic library to guess the type of files we're dealing with, for instance when we need to decide between rendering a file (for text files) or downloading it (for binary files). Here comes the tricky part: the Python bindings for libmagic are not the same in Debian and Pypi. Debsources uses Debian package python-magic, which is not in Ubuntu 12.04. Moreover, there's no Python egg for it on Pypi, which has however another package (called magic) which provides a different API. I solved this with a dirty hack, using the fact python-magic lies in a single file: It simply downloads the library, saves it in a temporary folder and includes it in the Python path. Let's see for how long it works before everything breaks! Size of a directory One test in the suite was ensuring the information returned by ls -l on a directory and stored in the DB was the right information. Inode metadata was tested, such as name, permissions, type, or size. Interestingly enough, the size of a directory was tested, and expected to be 4096 bytes. The size of a directory actually depends on the filesystem in use, and on the number of files this directory contains. We often see 4096 because it's the size of a not-too-big directory on ext4. Travis-CI doesn't use ext4: Simfs is a container filesystem for OpenVZ, on which directories have different sizes than on ext4: Directory sizes are not even powers of 2. Hence I changed the test to not check directory sizes. Hopefully this will help to make Debsources work on more filesystems! An empty file is hiding Last but not least, because this bug is still open in the wild. A file, which appears to be empty, is not taken into account by Debsources' updater. This file is sources/non-free/m/make-doc-non-dfsg/4.0-2/.pc/applied-patches. It is present in the filesystem in the container, is not the only empty file over there, but still doesn't appear in the database, and make fail the test which counts files. The test has been commented out (booooooh), so that we still can use Travis-CI's platform for our GSoC students, before it's fixed. Conclusion Making Debsources run automatically on a different platform as the one we usually use permitted us to spot bugs, write dirty hacks, and expand the filesystems it's supposed to run on. Now, let's hope the continuous integration will help our GSoC students, and let's wish them good luck!

Things haven t gone well recently. I have been working on refactoring stuff for the past two or three weeks. At first, I found it much more exciting and interesting than merely fixing minor bugs. So I worked on most parts of the codebase, and made lots of changes. It took me much more time and energy to do all this stuff. But sadly, the more energy results in a more broken codebase. It seems all these efforts are a waste since the code is no longer be able to be merged. It was very frustrating. Get back on track Well, I guess such trials and failures are just inevitable on the way towards an experienced developer. Despite all the divergences and dismay I have gone through, my internship must be back on track. I am now more realistic. My first and foremost task is to GET THINGS DONE by focusing on small and doable changes. Although it seems the improvement is LESS, but it means MORE to have a not-so-perfect finished-product (in my view), rather than a to-be-perfect messy. Journey continues.

In the middle of OPW internship I originally thought taking part in FOSSOPW is a great chance to lift my coding skills and I shouldn t miss it. As time passes by, I now have a new thought towards it. # 1 It do improves your coding skill. Zack, Matthieu and I often have discussions on coding style. For example, once Zack said, For code like this, you should explicitly use an if/else clause, not if-return. I was totally unaware of this sort of issue. Actually I even didn t know how I should call this problem. Matthieu gave me a detailed FYI link on this in no time. Besides, my completeness of thinking is also trained. Recently, I was fixing a HTTP GET Method ?suite=suite-name issue. It s a trivial task. And you know most trivial tasks require lots of scattered modification on the source code base. I did have fixed most places, such as the pages of /src/packagename and /search/ . Zack did a thorough review, and pointed out that the pages rendered by /prefix has some malformed urls in the HTML. Waiiiit, I should have noticed it. But somehow I missed it. Maybe because my mind was wandering at that time? This made me think, I shall have a thorough view of what I should do before getting my hands dirty. Or more preferably, if I could write down what I exactly want to achieve before coding, then silly problems definitely wouldn t occur. This may sound a little bit like TDD. ;). # 2 It makes you look like a (not-that-good) ninja. I use a macbook. It s not my fault! I ve tried several times, but I never successfully find a laptop that is not capable of boiling eggs when running Debian. (and especially KDE+Debian). So I have no way but switched to OSX. The development of Debsources happens on a remote Ubuntu LTS (now Debian SID, haha) virtual machine. Of course I have to install all the dependency on my own, e.g., Postgres, set up port-forwarding, e.g., ssh -D, write automate shell scripts, e.g., dash, but more importantly, I am forced to live under the dark terminal with no GUI. You know the feeling when pain hurts? Yes, exactly! But I survived. How shall I call myself now? A dedicated with-a-lot-of-useless-plugin-installed vimmer? A fond-of-fancy-window tmux-er? Yep, both. I finally found a comfort zone under the black-white-blinking screen. I wonder how people feel when they see a girl hanging out in the library, facing a full-screened black console, typing at a speed of 140wpm (Yeah, I am kidding). I don t know, but please don t call me a geek. Show me your respect, I am a ninja! # 3 It tells you communication is the most important. I bet anyone who has participated in a group-based project would understand what I mean. For one perspective, communication helps to eliminate misunderstanding. So I won t doing some useless stuff for all day and finally find out that it totally doesn t meet the requirement. On the other hand, it speeds up your learning process. I often have problems on git. So in the email I will complain if I mess up with the git repo. After a short while, my dear mentors will reply in detail on how to correctly do the git stuff. My OPW journey is cool! ;).

The Tropy In this period, I have tackled several bugs and got them finally about to be merged in the codebase. Namely, they are:
#761121 allow symbolic links within same version, #761861 override detected language type. I also spent some time on making debsouces runnable on sor.debian.org.
But still there is some db related problem on it. I am not quite familiar with psql, and kinda at a loss as what to do. Zack said he would take it over and I shall focus on what really I likes. Cool. For some non-code tasks, I have a detailed read on machine-readable debian/copyright . The other task is on flask blueprint . The idea of flask blueprint , as far as I am concerned, is sort of what apps are in django. Zack has drafted a specification on debian/copyright which serves as the goal of copyright.debian.net. Combined with the above reading knowledge, and with the help of Flask expert matthieu, I will get my hands dirty in the comming weeks to create a fantastic new site, aka, copyright.d.n. Stay tuned. some thought I did spend some time learning how to use git, and read quite a lot of materials. But, I shamely forgot most of them. So when I am frequently using git these days, I feel kinda incompetent and sometimes awkward. I am thinking now, maybe I shall stop overlearn some technology that I might never use. Only real usage and practice could help me get comfort with those tools. Overlearn something which I am not currently using and either won t in the future might just be a waste of time. and finally, I spent a great Christmas. Wish everyone happy, and merry Christmas!

Down the rabbit hole Starting from this week, my OPW period officially begins.
I am thankful and very grateful to this chance. One for the reason I can get an opportunity to contribute to a beneficial, working, meaningful, real-world software. The other seemingly reason is, I can learn much experience and design philosophy from my mentors zack and matthieu. :) This week my fix is on, bug #763921. It s basically making the folder page rendering providing more information, specifically the ls -l format. This offers information such as filetype, permission, size, etc. I learned some new knowledge about man 2 stat , and also got more familiar(actually confident) with front end stuff, namely css. I also get myself familiar with the python test (coverage). Next week, I will try to increase the test coverage a bit. Tests is an essential part of software. It ensures the correctness and robustness. And more importantly, by making tests, we can easily debug the software. The so called, The trello cards of next week is interesting. (in case you dunno the site, it s here:http://trello.com Let s see it.

Jingjie Jiang selected as OPW intern for Debsources I'm glad to announce that Jingjie Jiang, AKA sophiejjj, has been selected as intern to work on Debsources as part of the FOSS Outreach Program (formerly known as Outreach Program for Women, or OPW). I'll co-mentor her work together with Matthieu Caneill. I've just added sophiejjj's blog to Planet Debian, so you will soon hear about her work in the Debian blogosphere. I've been impressed by the interest that the Debsources proposal in this round of OPW has spawned. Together with Matthieu I have interacted with more than a dozen OPW applicants. Many of them have contributed useful patches during the application period, and those patches have been in production at http://sources.debian.net since quite a while now (see the commit log for details). A special mention goes to Akshita Jha, who has shown a lot of determination in tackling both simple and complex issues affecting Debsources. I hope there will be other chances to work with her in the future. OPW internship will begin December 9th, fasten your seat belts for a boost in Debsources development!

I m very excited about being accepted to the Debsources project in OPW. I ll record everything about my adventure here. Cheers ^_^