Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2014-03-17 22:03:00
Size: 2913
Editor: ?VladBogolin
Comment:
Revision 3 as of 2014-03-19 22:41:36
Size: 8585
Editor: ?VladBogolin
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
''To fill this in, copy the source text. Please '''don't''' rename the template.''  * '''Name''': Simion Vlad Bogolin
Line 6: Line 6:
This is a suggestion for the kind of information we'll find useful from students in their submissions. Remember -- you're going to be committing to several months' work. The more information and planning you can provide up-front, the more we (and Google!) will have to go on when we're ranking your application. Do not forget adding your submission at [[SummerOfCode2013/StudentApplications]]  * '''Contact/Email''': email - vladbogolin@gmail.com, irc - vladbogo
Line 8: Line 8:
 * '''Name''': Simion Vlad Bogolin
 * '''Contact/Email''': email - vladbogolin@gmail.com, irc - vladbogo
 * '''Background''': something about yourself: technical skills, experience, etc. Who are you? What makes you the best person to work on this project?
I am a fourth year student at "Politehnica" University of Bucharest, Computer Science and Engineering Department. The main areas that I am interested in are: algorithms, computer graphics and operating systems. 
 * '''Background''': I am a fourth year student at "Politehnica" University of Bucharest, Computer Science and Engineering Department. The main areas that I am interested in are: algorithms, computer graphics and operating systems.
Line 13: Line 10:
My skills consist in a strong background in algorithms and data structures. As it comes to programming languages I prefer C/C++ and Java, in which I also have more experience (about 2 years in Java and more than 6 years with C). Apart C/C++ and Java, I have experienced the next programming languages: Python, Haskell, Scheme, Bash Scripting, Matlab, Assembly language, Clips, Prolog. When it comes to versioning tools, I am quite familiar with Git (I have developed several school team projects using it) and SVN (which I used during last summer GSoC and also for some school projects).     * Skills: My skills consist in a strong background in algorithms and data structures. As it comes to programming languages I prefer C/C++ and Java, in which I also have more experience (about 2 years in Java and more than 6 years with C). Apart C/C++ and Java, I have experienced the next programming languages: Python, Haskell, Scheme, Bash Scripting, Matlab, Assembly language, Clips, Prolog. When it comes to versioning tools, I am quite familiar with Git (I have developed several school team projects using it) and SVN (which I used during last summer GSoC and also for some school projects). Also, I have some experience with Qt: last year during GSoC I developed a display manager for BRL-CAD using Qt. A display manager is the primary means with which BRL-CAD interacts with geometry.
Line 15: Line 12:
 * '''Project title'''
 * '''Project details''': a more detailed description.
 * '''Synopsis''': a short description.
 * '''Benefits to Debian'''
 * '''Deliverables''': quantifiable results e.g. 'Port Debian to VAX', 'Write 3 articles for X website'.
 * '''Project schedule''': how long will the project take? When can you begin work?
 * '''Exams and other commitments''': do you have university exams inside the SoC period? If so, that's most likely not a problem but please tell us early!
 * '''Other summer plans''': are you getting married? Do you have a long vacation planned? Are you expecting to start a job? '''Be aware''' that if you are accepted for the summer, then Google will be paying you as though you were working for them. We (in Debian) will therefore expect you to be working 35-40 hours per week on your project. It is very unlikely that you will be able to combine a successful SoC with another summer job working for somebody else.
 * '''Why Debian?''': Why are you choosing Debian? What attracts you about Debian?
 * Are you applying for other projects in SoC? Note that letting us know about this '''does not''' impact your chances of acceptance or rejection with us; we ask this because it helps us to resolve deduplications wherein a student is accepted for multiple projects.
    * Why me?: First of all, I am really enthusiastic to work to open source projects. Also, I must say that I consider that I have all the necessary skills in order to complete this project. I do not back away from difficult tasks and I am fully committed to finishing the project. I also plan to be an active developer after GSoC is over. Least but not least, I think that this is a great opportunity to learn new things that will help me in my future career, so this makes me even more enthusiastic about the project.

 * '''Project title''': Get Muon ready

 * '''Project details''': The Muon Package Manager is a powerful package manager aimed towards the intermediate - power-user range. It offers complete control over your packages with an interface that still keeps usability in mind. The first goal of the project is to get Muon in Debian, but also the project aims to improve Muon (see details below).
    
    * Getting Muon ready: I started by building Muon on Linux Mint and on Debian to see what needs to be fixed in order to have a fully functional Muon in Debian. After a little bit of struggle, I managed to successfully build Muon on both systems:





So, as it can be seen in the above pictures some menu entries are missing and also the toolbar cannot be shown. Below you can find a step by step plan in order to have a successful project:

          * Step 1: Solve the differences in the graphical user interface: have all buttons, menu entries and every other aspect of the interface shown.
          * Step 2: Checking the packages in order to make sure that all of them are shown and can be found from the interface
          * Step 3: Installing packages: installing a packages, installing multiple packages
          * Step 4: Removing packages
          * Step 5: Checking that the status of the packages is consequent with the system
          * Step 6: Checking that updates are found and can be installed
          * Step 7: Making sure everything in the interface works as expected
          * Step 8: Testing - different scenarios will be tested for every item: for example for the “Apply changes” button it should be tested the fact that it installs, removes, installs and removes packages.

Below, you can find attached the required addon with my name added to the “About Muon” window:

    * Muon improvements:
          * Improve search: At the moment, the quick search has a quite weird behaviour: sometimes as long as you type, the number of hits decreases at first to just a few then increases considerably, even though the query is more specific. This improvement aims to make an “incremental” search that will show proper results. I’ve chosen this improvement to work at because I think that will help users find the package faster, especially when they do not know exactly the name, just a keyword.
        * Related issue link: https://bugs.kde.org/show_bug.cgi?id=276338

   * Small fixes:
        * Making easier for users to see what filters they have applied: Since filtering is an “and” operation, when changing the filtering tab it can become unclear what filters are active so a way of notifying the user what filters are active or an option to deactivate all filters should be provided.
        * Related issue link: https://bugs.kde.org/show_bug.cgi?id=327923

      * Saving the changes list so that it can be restored if download fails. The user will not have to select everything again.
        * Related issue link: https://bugs.kde.org/show_bug.cgi?id=308601

 * '''Synopsis''': Getting Muon, the apt frontend written by and for Kubuntu, in Debian. There are a great bit of ubuntu specific data that needs to be fixed up and provided in Debian. Besides this, the project aims to add a set of improvements to Muon.

 * '''Benefits to Debian''': The main benefit for Debian would be the fact the it is going to have a new package manager that would help users install/manage packages easier.

 * '''Deliverables''': A fully functional Muon in Debian.

 * '''Project schedule''': I will be able to start effectively working at the project from the start of the coding period. I will use the community bonding period to get more familiar with the code, to discuss with my mentors to see if I haven’t missed anything so that I can start writing code from the beginning of the coding period. Below you can find a more detailed schedule:

       * Community bonding: discuss with mentors, research, get familiar with the code
       * Week 1: solving the graphical issues - items not shown. At the end of this week all items should appear even though their behaviour might not work yet.
       * Week 2: make sure all packets appear in the interface, start working at the “Apply changes” behaviour
       * Week 3: finish applying changes and testing. Also, I saved some time for unexpected problems that might appear (bugs).
       * Week 4: dealing with package updates, checking package status and any other things that need to be done so that Muon is fully functional in Debian.
       * Week 5: testing to make sure that everything works as expected. Also, preparing for midterm evaluation.
       * Week 6-9: working at the search feature: design of an algorithm, implementation and testing
       * Week 10: more testing and time reserved for unexpected problems. Start working at the “small fixes”
       * Week 11-12: finish working at the “small fixes” and testing.
       * Week 13: final testing and preparing the final evaluation

The above schedule is orientative. I tried making it as realistic as possible and reserved time for unexpected problems that might appear. If everything goes fine and finish all the features earlier, I will start working at other improvements.

 * '''Exams and other commitments''': The starting coding period overlaps a bit with my exam period (I will probably have one or two exams in the last weeks of May), but this shouldn’t be an issue: if necessary I will start coding earlier so that everything goes according to schedule. Also, in July I will have my final paper presentation (one or two days). This shouldn't be an inconvenient because I plan to have my final paper done until the coding period starts.
 
 * '''Other summer plans''': No other plans.

 * '''Why Debian?''': For the past 4 years, I use linux as my main operating system, especially for programming projects. Even though I tried quite a few distributions during the years they were all Debian based. Last year, I took an operating system course and I started to develop my passion for this field. The things I learned in this course (about OS internals) made me have a deeper understanding of how computers are working which can only be translated in a better, more optimized code. Now, I pursue an advanced operating system course (kernel programming) and I find it very interesting and useful. Even though my selected project aims on the interface and on the user aspect, I’ve chosen Debian I will have the chance to work in the future on both sides: kernel side and user side.
 
 * Are you applying for other projects in SoC?: Yes, I am applying for other GSoC projects.

Finally, I want to thank you for taking time to read my proposal. I hope we will collaborate during this summer but also after GSoC.

Student Application Template

  • Name: Simion Vlad Bogolin

  • Contact/Email: email - vladbogolin@gmail.com, irc - vladbogo

  • Background: I am a fourth year student at "Politehnica" University of Bucharest, Computer Science and Engineering Department. The main areas that I am interested in are: algorithms, computer graphics and operating systems.

    • Skills: My skills consist in a strong background in algorithms and data structures. As it comes to programming languages I prefer C/C++ and Java, in which I also have more experience (about 2 years in Java and more than 6 years with C). Apart C/C++ and Java, I have experienced the next programming languages: Python, Haskell, Scheme, Bash Scripting, Matlab, Assembly language, Clips, Prolog. When it comes to versioning tools, I am quite familiar with Git (I have developed several school team projects using it) and SVN (which I used during last summer GSoC and also for some school projects). Also, I have some experience with Qt: last year during GSoC I developed a display manager for BRL-CAD using Qt. A display manager is the primary means with which BRL-CAD interacts with geometry.
    • Why me?: First of all, I am really enthusiastic to work to open source projects. Also, I must say that I consider that I have all the necessary skills in order to complete this project. I do not back away from difficult tasks and I am fully committed to finishing the project. I also plan to be an active developer after GSoC is over. Least but not least, I think that this is a great opportunity to learn new things that will help me in my future career, so this makes me even more enthusiastic about the project.
  • Project title: Get Muon ready

  • Project details: The Muon Package Manager is a powerful package manager aimed towards the intermediate - power-user range. It offers complete control over your packages with an interface that still keeps usability in mind. The first goal of the project is to get Muon in Debian, but also the project aims to improve Muon (see details below).

    • Getting Muon ready: I started by building Muon on Linux Mint and on Debian to see what needs to be fixed in order to have a fully functional Muon in Debian. After a little bit of struggle, I managed to successfully build Muon on both systems:

So, as it can be seen in the above pictures some menu entries are missing and also the toolbar cannot be shown. Below you can find a step by step plan in order to have a successful project:

  • Step 1: Solve the differences in the graphical user interface: have all buttons, menu entries and every other aspect of the interface shown.
  • Step 2: Checking the packages in order to make sure that all of them are shown and can be found from the interface
  • Step 3: Installing packages: installing a packages, installing multiple packages
  • Step 4: Removing packages
  • Step 5: Checking that the status of the packages is consequent with the system
  • Step 6: Checking that updates are found and can be installed
  • Step 7: Making sure everything in the interface works as expected
  • Step 8: Testing - different scenarios will be tested for every item: for example for the “Apply changes” button it should be tested the fact that it installs, removes, installs and removes packages.

Below, you can find attached the required addon with my name added to the “About Muon” window:

  • Muon improvements:
    • Improve search: At the moment, the quick search has a quite weird behaviour: sometimes as long as you type, the number of hits decreases at first to just a few then increases considerably, even though the query is more specific. This improvement aims to make an “incremental” search that will show proper results. I’ve chosen this improvement to work at because I think that will help users find the package faster, especially when they do not know exactly the name, just a keyword.
  • Small fixes:
    • Making easier for users to see what filters they have applied: Since filtering is an “and” operation, when changing the filtering tab it can become unclear what filters are active so a way of notifying the user what filters are active or an option to deactivate all filters should be provided.
    • Related issue link: https://bugs.kde.org/show_bug.cgi?id=327923

  • Synopsis: Getting Muon, the apt frontend written by and for Kubuntu, in Debian. There are a great bit of ubuntu specific data that needs to be fixed up and provided in Debian. Besides this, the project aims to add a set of improvements to Muon.

  • Benefits to Debian: The main benefit for Debian would be the fact the it is going to have a new package manager that would help users install/manage packages easier.

  • Deliverables: A fully functional Muon in Debian.

  • Project schedule: I will be able to start effectively working at the project from the start of the coding period. I will use the community bonding period to get more familiar with the code, to discuss with my mentors to see if I haven’t missed anything so that I can start writing code from the beginning of the coding period. Below you can find a more detailed schedule:

    • Community bonding: discuss with mentors, research, get familiar with the code
    • Week 1: solving the graphical issues - items not shown. At the end of this week all items should appear even though their behaviour might not work yet.
    • Week 2: make sure all packets appear in the interface, start working at the “Apply changes” behaviour
    • Week 3: finish applying changes and testing. Also, I saved some time for unexpected problems that might appear (bugs).
    • Week 4: dealing with package updates, checking package status and any other things that need to be done so that Muon is fully functional in Debian.
    • Week 5: testing to make sure that everything works as expected. Also, preparing for midterm evaluation.
    • Week 6-9: working at the search feature: design of an algorithm, implementation and testing
    • Week 10: more testing and time reserved for unexpected problems. Start working at the “small fixes”
    • Week 11-12: finish working at the “small fixes” and testing.
    • Week 13: final testing and preparing the final evaluation

The above schedule is orientative. I tried making it as realistic as possible and reserved time for unexpected problems that might appear. If everything goes fine and finish all the features earlier, I will start working at other improvements.

  • Exams and other commitments: The starting coding period overlaps a bit with my exam period (I will probably have one or two exams in the last weeks of May), but this shouldn’t be an issue: if necessary I will start coding earlier so that everything goes according to schedule. Also, in July I will have my final paper presentation (one or two days). This shouldn't be an inconvenient because I plan to have my final paper done until the coding period starts.

  • Other summer plans: No other plans.

  • Why Debian?: For the past 4 years, I use linux as my main operating system, especially for programming projects. Even though I tried quite a few distributions during the years they were all Debian based. Last year, I took an operating system course and I started to develop my passion for this field. The things I learned in this course (about OS internals) made me have a deeper understanding of how computers are working which can only be translated in a better, more optimized code. Now, I pursue an advanced operating system course (kernel programming) and I find it very interesting and useful. Even though my selected project aims on the interface and on the user aspect, I’ve chosen Debian I will have the chance to work in the future on both sides: kernel side and user side.

  • Are you applying for other projects in SoC?: Yes, I am applying for other GSoC projects.

Finally, I want to thank you for taking time to read my proposal. I hope we will collaborate during this summer but also after GSoC.