wiki:SummerOfCode2013

Roadmap

Week # 0

A few days until the actual coding period began, and I was still getting to know the developers. The MacPorts codebase is fairly large, and it will take a while until I will figure out all the ins and outs. I have created my development branch and made my first commits.

Rainer, together with Clemens and Jeremy, met me on the IRC channel and we all set the course for the first week of the coding period. We all decided that I should begin by improving the existing regression tests, converting them to use the TCLTest framework, while keeping them as modular as possible, making it easy to add new test cases. I have received my assignment and it's up to work from now on.

Week # 1

After the first week, it seems that I am on the right track. Rainer is pleased with the testing framework that we have chosen to use and he feels that this project is heading to the right way.

The checksum test consists of three sub-tests, one for each checksum (md5, sha1, rmd160). The calculated values are gathered from the output of the 'port test' command, using the debugging mode ('-d') and compared to the expected ones, using the tcltest framework. I have tried to make the code as modular as possible, but Rainer has suggested some further improvements, that I will implement the following week.

With the help of Clemens and Jeremy, I have been described the functionality of the remaining regression tests and this has helped me enhance my understanding of how MacPorts works. In the next week, I will focus on the dependencies tests and will try to pick up the pace and commit more often so they can be up to date with my evolution.

Week # 2

During the second week of development, I have continued to improve upon existing regression tests: dependencies, envvariables, case-sensitive and site-tags tests. I have modified the tests to use a common proc library and started working on a method that will allow all the test to be ran at the same time.

After reviewing my code, the guys have stated some changes that they would like to see and which will be implemented later in the third week. We all have agreed that I should continue to work on the existing tests the following week, although this involves changing our roadmap a bit.

Week # 3

This week was all about tweaking all the work that I have done so far. All paths had become absolute, the trace test has been completed and cleanup has been done. I had also added a script that would run all available regression tests and display the results in an easy to read way, besides a Makefile that would run them automatically once all MacPorts tests are run.

The next week, I will head my attention on unit tests. There is a lot of work to be done with modules as port1.0, registry2.0, machistal1.0 and although there are many parts of code that I don't really understand at this moment, Rainer, Clemens and Jeremy are always there to help me, besides the people of the community who are always active on IRC.

Week # 4

A week into unit testing, and it seems work will never end. There are a lot of procs that need to be tested and the code is very hard to read and understand. I have managed to make a few tests, but only with the help of my mentors (our weekly meeting really helps a lot). For the next week, I want to increase the pace and put as much time as I can into development.

Week # 5

Things are getting better and better, as I need less and less help from my mentors. I have managed to cover 3 of the modules of port1.0 (portactivate, portclean and portutil), but I have developed enough confidence to step up the pace and increase my developing speed. The tcltest framework really seems a great fit for our needs, fact confirmed by Rainer. Still a lot of work needs to be done, and as wee discussed on our last meeting, we may need to reorder some things in our roadmap for this summer, but not after we talk to the rest of the community and listen to the other developers' opinions.

The need for good documentation is really felt, once I dig deeper into the functionality of MacPorts, so I will make sure the test I develop come with good instructions on how to use the framework, add new tests to it or change it. I have already started with short comments in the code and some README files that will help me write the final documentation. The midterm evaluations is near, so I'd better get back to work.

Week # 6

Everything is running smoothly. This week, I have added tests for: portdistcheck, portload, portinstall, portuninstall, portfetch, portdepends, portchecksum. I believe, and my mentor has confirmed that I should move on to testing another part of MacPorts, as I have already covered the most important procs of port1.0. So, for the next week, I will handle registry2.0.

It's the half of the coding period so I will also have to submit my midterm form. I hope no problems appear.

Week # 7

We are passed midterm evaluation and running into the second coding period, starting with a week focused only on package1.0 unit tests. I have managed to cover most of the procs in this package and, with Clemens' help, I have fine tuned them to be really efficient and as modular as possible. I really wish I could reward my mentors for all the help that they offer, but I guess seeing me integrating in the community and helping them back with the development is really what matters from them.

Week # 8

I have started work on macports1.0 tests. It seems that one week is not enough for this, so I may continue with this the following week, without affecting the proposed schedule. This is a very important part of the MacPorts codebase so I have to be very thorough. I have also found a bug that i have fixed, but it proved that code is no longer used so it will be removed soon. After the summer is over, I plan to remove old code, that is no longer used, as I believe this is one of the things that drags MacPorts down.

Week # 9

We had some problems when Clemens, Rainer and Jeremy had run the tests on their systems. It seems like, while it works perfectly on my computer, having custom configuration files, installing MacPorts from other sources and small other things affect the functionality of the framework.

So the following week I will continue to tweak and patch the system as to be ready for integration with the current, up to date, code of MacPorts, as we all consider this to be more important, at this point, than writing the documentation, which will not be forgotten. With Clemens' help, I should be able to finish all the problems that we has summarised in the end of our meeting, in time, and everyone should be able to run the framework, at the end of the week.

Week # 10

Finally finished and tested (in all cases) the output of the script that runs all the tests inside a module. The output is very clean and easy to read. The file can now be copied to all the other modules without any problems. I will do that the following week. I have also fixed all the problems we had last week, when we ran the tests on systems with different configurations, with Clemens' help.

I have also started working on the documentation as well as the test templates. After my mentors gave be the thumbs up, I have moved it on the MacPorts site. There are still a lot of things to do, but I am really anxious to see my code moved to trunk and everybody using it.

Week # 11

We are getting closer and closer to the end of the project, so it's all hands on reviewing and refining the last test cases. The documentation is getting in shape and we are making sure the tests will run on any custom configuration and on any system. Having a relative source path for macports_fastload.tcl seems to cause some trouble, but we hope to fix that soon.

Week # 12

This week I had further improved the documentation, adding info about the output of the testing framework (constraints, errors), as well as a short description about its file hierarchy. I had also fixed portactivate, portdeactivate, portpatch and portdistcheck tests.

For the 'source macports_fastload.tcl' problem, the best solution we found is to use an autoconf file that would set the variable containing the absolute path of the file. This would be implemented the following week.

Week # 13

In this week we discovered some tests in package1.0 had some problems running, after we updated to using an absolute path for macports_fastload.tcl. This was fixed by updating the ports tree before running the tests, so we have added the command to the Makefile so this would be done automatically when the tests are run. Tests for portrpm.tcl and portsrpm.tcl have been removed, since that code is no longer needed. We have also found problems on parsing the output for some tests (those who had custom constraints) and some tests that needed root privileges, but those were quickly fixed.

We finally merge to trunk. :D Conflicts are easily resolved, last minute patches are added, everything runs smoothly.

---

Personal

  • Name: Marius - Vlad Coțofană
  • E-Mail: marius.coto@…
  • IRC/IM: mariusc (IRC), cmarius02 (GTalk, Skype)
  • University/Enrollment: "Politehnica" University of Bucharest, studying Computer Science, 2nd year.
  • Location/Timezone: Bucharest, Romania (GMT+2)
  • Programming Knowledge: C/C++, Java, Python, Shell Scripting (bash).
  • Short Bio:

Hypnotised by computers from an early age, I began programming in high school. Learning C opened a new world for me and changed the way I used to see a computer. I followed Computer Science at the University, that brought me a whole range of other programming tools and languages, but C remained my favourite. I have adopted Linux, for almost 2 years, learned it, used it, taught it to other students and then decided to move on. OS X offered a new experience, much powerful and sharper and I decided to further improve it.

Detail-oriented and highly analytical person, I have always tried to get involved in as many projects as possible, get around people that are better trained than me and learn from any experience. Although it takes me some time to connect to new people, I am devoted and helpful in any circumstances. Stubborn and punctual, I cannot stop until all work is done.

Project

ABSTRACT

The lack of a proper testing environment is slowing down the development of the main project. Having an improved testing framework, that makes it easy for adding new tests and having a more comprehensive suite of tests, is essential to being able to refactor the code correctly. This also leads to an decrease in the time needed for adding new features and patches.

DETAILS

I will begin by setting up the necessary development environment, 2 weeks before the actual beginning of the coding period, time in which I will also make sure I have iterated through all of the Tcl features and I have a good understanding of how MacPorts source code is structured.

In the first half of the coding period, I will review existing tests and further enhance them. This will walk me through the way they are constructed, so that I can maintain a consistent form and syntax throughout the entire testing framework. Having gain a sense of how things work, I can then begin writing new tests that will first cover the most important modules, and then continue and try to get as much coverage as possible.

The second part will be focused on regression tests: improving existing ones and possibly adding new ones. Testing every part of the code is a good way of assuring correct behaviour, but as more and more functionality is added, new tests have to be added too. I will build an easy way of adding new tests, consisting in templates that are easy to use and understand. Having good documentation over the testing framework, is one of the objectives that would also be covered during this period. This will ease the work of people who want to add more tests or further extend the framework, and being open-source, inspire people who need testing for their own projects.

Below you can find a tentative timeline, structured in 2-week intervals, as a generalised form from this detailed plan.

TIMELINE

Community bounding (1 June - 16 June):

  • prepare development environment
  • further read on Tcl
  • study MacPorts sources

First coding period (17 June - 28 July):

  • 17 Jun - 30 Jun: review existing tests and improve them
  • 1 Jul - 14 Jul: add unit tests for MacPorts base and the Portfile API
  • 15 Jul - 28 Jul: add more tests that cover all modules

Second coding period (29 July - 8 September):

  • 29 Jul - 11 Aug: improve available regression tests (and possibly add new ones)
  • 12 Aug - 25 Aug: build a new, easy way for adding new tests
  • 26 Aug - 8 Sep: write full documentation for the testing framework
  • 9 Sep - 17 Sep: review code

The remaining time between suggested 'pencils down' and firm 'pencils down' serves as buffer for unexpected changes and delays.

Additional Questions

  • What are your experiences with Mac OS X so far? (How long do you use it, did you switch from Windows/Linux, etc.)

I started using Mac OS X just 5 months ago (December 2012), when I bought a new notebook. Coming from a Linux world, I decided to switch because it had so many problems that I had to spend most of the time repairing them, rather than spending it developing. Of course, OS X, has its problems too, one of which is the lack of a proper package manager. MacPorts is a great solution to this problem, so I plan to be part of it.

  • Have you used MacPorts before, and if yes, for how long?

I have used MacPorts since my first week with OS X (5 months ago), like one of my friends suggested, as a response to my complaints.

  • Do you have experience with other package management systems such as FreeBSD ports, Gentoo Portage, Debian APT, etc.?

I have previously used many Debian-based distributions so I am familiar with DPKG and APT, but also tried YUM and RPM.

  • Have you already made contributions to MacPorts? (New ports, port updates, etc.)

No contributions yet. I have focused on reading the code and understanding how it works. I plan to have my first commits before the coding period begins.

  • Have you already made contributions to other Open Source projects?

Sadly, I do not have any major contribution to other Open Source projects, and that is the reason why I am so exited to start this project.

  • How much experience do you have with Tcl and C?

C was my first programming language and quickly became my favorite. I began writing C code from high school and continued with it two years in my university studies, where I have also added POO notions (C++). This language has proven to be very powerful and feature rich, that is why I plan to stick to it.

I began learning Tcl for two weeks, starting with the tutorial on the official site (as people from the MacPorts IRC-channel suggested) and already have made some scripts to further understand its features. My little experience with Tcl is backed up by a fairly large history (2 years) with shell scripting using bash.

Last modified 4 years ago Last modified on Sep 19, 2013, 9:53:14 PM