Student Application Template
Name Sam Lidder
Contact/Email:
<sam.lidder AT gmail DOT com>
- acx0 on Freenode, OFTC
- EDT/GMT-4
Background: I am a second year Computer Science student attending Ryerson University in Toronto, Canada. I'm a highly passionate programmer who loves working with and contributing to GNU/Linux and open source software. Some of my contributions can be found here: github.com/acx0. I've been a Debian user for about 4 years now and would love to contribute to the project. I've been programming for about 5 years now and primarily use C++, Java, and C, for larger projects and competitive programming, and Bash, Python, VimL, for creating shell utilities and scripting tasks.
- My interests include learning about complex and lower level pieces of software such as operating systems, compilers, and package managers. I also have a passion for learning about higher level computer science concepts such as the study and design of algorithms and data structures. I believe I would be a perfect match to work on this project since I am passionate about the work and willing to put all my effort into it. I believe my drive and enthusiasm for working with Debian GNU/Linux, my knowledge of algorithm design principles, and experience of software engineering practices will give me the perfect balance of experience and skill required to work with this project.
Project title: Pluggable acquire-system for APT
Project details: The project will deal with unifying package management tools that are used to acquire metadata about software packages (such as information about files in packages, and debtags) allowing APT to deliver a more consistent, secure, and efficient user experience.
Synopsis: Create a unified backend to manage package metadata, allowing Debian's package management system to manage large sets of data in a more efficient, secure, and flexible manner.
Benefits to Debian: The purpose of the project is to improve and extend an existing tool which is a core part of Debian. The improvements made to APT will provide a more consistent user experience for Debian users and would also make the tool simpler in nature and easier to use for newcomers as well as experienced users. Extending APT to include a plugin system would also make it much more flexible and powerful, giving users more control of their systems. This new framework might even motivate users to contribute ideas and code for plugins and also get involved with the Debian development community.
Deliverables: The end results of the project will include a parser for sources.list which has the ability to understand configuration settings for individual sources. This would allow for functionality such as disabling plugins for certain sources and having unique configuration settings local to each repository source. Plugins to download packages, sources, and translation files will also be written along with any others that are proposed and deemed useful or worthy. The project would also cover refactoring and improving the acquire framework which is part of apt's codebase.
Project schedule:
April 24 - May 20: Community Bonding Period
- April 24 - May 1 (1 week)
- get in touch with mentor
- get comfortable with project codebase structure
- read documentation, coding conventions
- May 2 - May 7 (~1 week)
- setup version control repository for student's contributions
- setup and become familiar with build environment, build tools, and test suite
- discuss special topics specific to project with mentor (e.g.: project's preferred development cycle)
- review proposed project schedule and make changes where appropriate
- May 8 - May 20 (~2 weeks)
- review knowledge of concepts required for project
- inter-process communication:
- semaphores, (named) pipes, message queues, signals, etc.
- security concepts
- methods of authentication used in project (hashing, key signing)
- common types of attacks and their prevention (MITM, compromised key attack, identity spoofing)
- core elements of a parser
- study and understand abstract package list parser class and implementation of deblistparser (from APT's source)
- inter-process communication:
- begin reviewing existing elements of APT's source which will be used during the project
- review knowledge of concepts required for project
- April 24 - May 1 (1 week)
May 21 - July 20:
- May 21 - May 28 (1 week)
- draft a high level abstract model of the pluggable architecture for the acquire system
- define how it will behave, and interact with existing APT code
- draft a high level abstract model of the pluggable architecture for the acquire system
- May 29 - June 12 (2 weeks)
- plan how existing acquire tools will be refactored to fit newly designed pluggable architecture
- begin working with existing tools for parsing sources.list and modify them to work with new proposed structure
- write test cases
- June 12 - June 19 (1 week)
- begin drafting structure of core plugins (for downloading packages, sources, translation files)
- June 20 - July 11 (3 weeks)
- begin implementing and working on core plugins
- work divided approximately into 1 week / plugin
- write test cases
- refactor existing code as needed
- begin implementing and working on core plugins
- July 12 - July 20 (~1 week)
- perform code review with mentor once core system is completed
- begin documentation of core functionality
- May 21 - May 28 (1 week)
July 21 - August 12:
- July 21 - July 28 (1 week)
- perform security audit on core architecture and plugins
- work on making system more robust against failure/malicious attacks
- perform security audit on core architecture and plugins
- July 29 - August 5 (1 week)
- begin finalizing work on core plugins, documentation, and tests
- August 6 - August 12 (~1 week)
- propose ideas for any other plugins that could be added to the core system
- if time permits, begin drafting and working on these (can even be contributed after the SoC period if not completed)
- propose ideas for any other plugins that could be added to the core system
- July 21 - July 28 (1 week)
August 13: Soft deadline for 'pencils down' date
- August 13 - August 19 (~1 week)
- perform final code review of project
- improve documentation
- write/verify tests (as needed)
- August 13 - August 19 (~1 week)
August 20: Hard deadline for 'pencils down' date
- project should be completed at this point
Exams and other commitments: I do not have any exams or other commitments during the SoC period.
Other summer plans: If accepted, I will only be working on the Debian GSoC project, and maybe on some other open source projects in my free time.
Why Debian?: To me, Debian is more than just a GNU/Linux distribution that I like to play around with. I see Debian as a philosophy that defines an extremely flexible and powerful way of computing so far ahead of the mainstream; one that seems to be a natural fit for any programmer that is serious about their craft. Although it's not just the philosophy that attracts me to the project, it's the community; the group of people willing to share their knowledge, wisdom, time, and efforts towards a unified goal while asking for nothing in return - the definition of passion. Where Debian stands out from all others, rests in the maturity, quality, and stability of the software it provides. It is apparent from the release cycle that the project places a very heavy emphasis on the quality of the work it produces. This is the kind of discipline that inspires and awes people to work harder to achieve the same results, and the kind that has definitely inspired me to become a better programmer.
- It wasn't until I developed this view of the project that I finally understood what it meant to be able to 'see further by standing on the shoulders of giants'. The Debian project has changed the way I work, the way I think, and the way I wonder of what is possible with computing - all for the better. For this reason alone I feel it is my responsibility to give back, if not for feeling obligated, then for the chance that someone else may experience what I have. I believe that regardless of whether I'm chosen to work on this project, I will very likely end up contributing to the Debian project in some way or another. This opportunity, though, would put me one step closer to accomplishing my goal of contributing as I would be able to spend time with a mentor who introduces me to the project environment and gives me critical feedback on my initial contributions.
Are you applying for other projects in SoC? No.
Bug Fixes: As an exercise to become more familiar with the codebase, I decided to attempt tackling a few bugs in APT. Attached are patches along with accompanying notes. If time permits, more patches will be added.
To test patches run patch -p1 < $patch-num.patch in top level of APT source directory.
- Notes:
renamed '?DumpPackage' function to '?DumpPackageInfo' to accommodate for extra parameter
- unsure about indentation conventions; appears to be 3 space indention
- although some lines have leading tab char and then 3 spaces/indent
- indented based on surrounding code (e.g.: leading tab + 3 spaces/indent)
- showpkg's "Dependencies:" list might be easier to read if it followed same format of "Reverse Depends" (one item per line)
- just a suggestion, didn't modify original behaviour
- Notes:
- version information not displayed for parent and virtual/non-real packages