Differences between revisions 20 and 21
Revision 20 as of 2014-03-17 00:21:10
Size: 6001
Editor: ?Andrei-MihaiNicolae
Comment:
Revision 21 as of 2014-03-17 01:00:53
Size: 6066
Editor: ?Andrei-MihaiNicolae
Comment:
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
Using the outcome of the GSoC 2012 project, botch, we can actually see most of the build dependencies that would be the best breakable "spots" in the graph. I have made patches for Redhat-cluster 3.1.8-1.1(patch1 patch2) and also doxygen( fortunately enough, there was someone else who patched it before, so I will not link the patches anymore; it was more for training (-:) which helped me gain some insight into what the work I will have to do during the summer will look like. Using the outcome of the GSoC 2012 project, botch, we can actually see most of the build dependencies that would be the best breakable "spots" in the graph. I have made patches for Redhat-cluster 3.1.8-1.1([[patch.diff | https://www.dropbox.com/s/ud8oaofg9w6z22p/redhat-cluster.diff]]) and also doxygen( fortunately enough, there was someone else who patched it before, so I will not link the patches anymore; it was more for training (-:) which helped me gain some insight into what the work I will have to do during the summer will look like.

Student Application Template

  • Name Andrei-Mihai Nicolae

  • Contact/Email: I am available on IRC ( nclandrei), GTalk( a.mihai.nicolae) and YM( andreinicolae1994), but I can also be contacted on Skype( nclandrei).The emails where I can be contacted are: a.mihai.nicolae@gmail.com andreinicolae1994@yahoo.com a.nicolae@jacobs-university.de

  • Background: I am a first year Computer Science undergraduate student at Jacobs University Bremen, Germany. I have always been passionate about computers and programming in general, having worked with C/C++ and Python since 8th grade. Now, I can say that I have extended my range of skills, varying from Javascript, HTML5, PHP to Java or even basic Scala.

Since the academical year started, I have already taken 2nd year courses, passing the Data Structures and Algorithms course and currently having Software Engineering, but I have also been employed at DFKI Bremen, the German Reasearch Center for Artificial Intelligence, where I have extensively worked with image processing, C/C++ complex algorithms, basic manipulation etc.

Debian-related, I have been using Debian since 2010, when my journey in the open source world also started. After seeing this project proposed, I have worked on my packaging abilities and eventually managed to patch, for example, redhat-cluster( 3.1.8-1.1) and doxygen (1.8.6-1) packages such that they will break cycles in the "build-dependency tree", thus I consider I am ready to take this task further on.

  • Project title: Bootstrapping Debian

  • Project details: While the main goal is to make Debian buildable using itself in order to, for example, bring up new architectures easier, but also make Debian self-supporting, what the project will be about is to fix the "odd" packages that will transform the build-dependency tree into an acyclic graph.

Using the outcome of the GSoC 2012 project, botch, we can actually see most of the build dependencies that would be the best breakable "spots" in the graph. I have made patches for Redhat-cluster 3.1.8-1.1(?https://www.dropbox.com/s/ud8oaofg9w6z22p/redhat-cluster.diff) and also doxygen( fortunately enough, there was someone else who patched it before, so I will not link the patches anymore; it was more for training (-:) which helped me gain some insight into what the work I will have to do during the summer will look like. Even though the deliverables of the project are pretty straightforward and the work will be done manually for each package, checking the bootstrappability status after every change, the difficulty of the project might vary from packages which have only one "should-be-broken" build dependency to source packages involved in Type-2 Self Cycles, for example(source indirectly strongly Build-Depends on a binary package it itself builds through one of its direct build dependencies). I think what will matter in thend will be a well-organized schedule to make our goal achievable. Moreover, being able to package will not be the only skill needed, good communication being required as well: a friendly relationship will have to be kept between the student and the package maintainers throughout the entire summer. In the end, there will be a snapshot taken and we will compare it to the original one, which is currently available at bootstrap.debian.net.

  • Synopsis: As the main task is to make Debian buildable on itself, making the process of bringing up new architectures easier and Debian self-supporting, changes will have to be made in the about 60 "odd" packages, eventually turning the cyclic build graph into an acyclic graph( build tree). Of course, this will be possible only with the acceptance of the maintainers of the packages, with whom there will be a permanent communication. At the end of the summer, the desired outcome would be to have Debian fully bootstrappable.

  • Benefits to Debian

    • make Debian properly self-hosting
    • allow new architectures to be brought up easier, thus making Debian's aim of becoming the "Universal OS" more approachable
    • building of Debian would become automated and, therefore very easy and deterministic
  • Deliverables: Will have fixed the ~60 "odd" packages, status of the bootstrappability of Debian.

  • Project schedule: The official timeframe is from May 19 to August 18, which means exactly 13 weeks. The project can be split as following:

    • (Up until May 18) Community bonding, working on "easier-to-fix" packages before the actual coding period starts
    • (3 weeks) Deal with the packages in the "Feedback Arc Set" ( for the 1st SCC) section from bootstrap.debian.net which are not involved in Type-1,2 and 3 Self-cycles.
    • (5 weeks) Solve the packages involved in Type 1, Type 2 and Type 3 Self-Cycles, as these will probably require the greatest amount of time.
    • (3 weeks) Focus on the other packages which have to be solved after we have analyzed the new snapshot( from where we can see where there is still work to do).
    • (2 weeks) Go through the other SCCs( which have way fewer vertices) to solve the remaining cycles.

Of course, another very important task throughout all weeks will be to maintain a permanent and friendly communication with the package maintainers such that there are no problems with submitting the patches.

  • Exams and other commitments: I will have exams from May 20 until June 8.

  • Other summer plans: Except a 3-4 days vacation at the beginning of August, I will work full time on the project. Obviously, I can recover these lost hours, as I am willing to work from 40 up to 45 hours/ week.

  • Why Debian?: The huge number of available packages, the possibility to easily choose wether you want to be on the stable release or switch to testing/ unstable, experience with Debian in general( around 4 years), excellent community, support for a wide variety of architectures.

  • Are you applying for other projects in SoC? Yes.