From Fedora Project Wiki

Contact information

Nick: squimrel

E-Mail: squimrel@fedoraproject.org

Blog: https://medium.com/@squimrel

Github: https://github.com/squimrel

About me

I’ve not had any past involvement with the Fedora project as a contributor and no notable contributions to other open-source projects.

I study computer science. I’m in my 4th semester bachelor. I originally started to study to get to know programmers who know what they’re doing and to expand my knowledge.

I’m motivated to give my best because I don’t want to annoy people with reading terrible source code or looking at partial solutions that were not thought through or not refactored before commit.

I usually don’t have much trouble staying focused but if I do have trouble then I surround myself with other people who’re also working on their project.

How I organize my work

  1. Split it up in tasks.
  2. Figure out if someone already solved the problem I need to solve in the task.
  3. Check if I can take a similar approach to the problem (if the approach was smart) and if there are other solutions to the problem. Repeat.
  4. Document all approaches that seem worthy to be mentioned.
  5. Implement the most beautiful and feasible solution.
  6. Open a PR.
  7. Move on to the next task.

Why I chose the Fedora Project

As a Fedora user and fan, the Fedora Project was definitely one of the organizations on the list that I would love to work with.

My decision was not primarily for the Fedora Project though but for the specific project I’d like to work on.

I currently don’t have plans to continue to contribute to the Fedora Project apart from helping to maintain the project I’ll work on.

Fedora Media Writer - Persistent storage

Even though I’m a user who hardly uses anything else than a terminal and a browser I’m a huge fan of cross-platform applications such as the Fedora Media Writer. I also think this is worth supporting since it can help my Windows friends to get started with Fedora.

I haven’t used this tool before I read its source code since I was fine with livecd-iso-to-disk on Fedora. In the end the source code and commit history convinced me to want to work on this project.

I did contact Martin Briza, the mentor and creator of the project.

Relevant experience

I’ve read the following books about C++:

  • Programming: Principles and Practice Using C++ (2nd Editon)
  • The C++ Programming Language, 4th Editon

and I followed CppCon 2015 and 2016 even though I’ve only watched about a third of the talks I learned quite a lot from them.

If you want to see C++ source code I wrote you may want to look at this tiny C++ project.

I also feel comfortable writing source code in various other languages and I’m fine following the implicit style guide the source code of the project was written in.

I’m mainly self-taught so I’ve experience in doing research about topics I know only very little about.

Gain

I’d like to

  • experience how it’s like to work with someone together on an open-source project that’s written in C++.
  • get my code reviewed by an experienced programmer such as Martin Briza and learn from it.
  • learn everything there’s to know about persistent storage.
  • learn as much as I need to know about Qt.

Final deliverable

The project is about adding support for persistent storage to the Fedora Media Writer. That means that a user who uses the Fedora Media Writer will be able to keep the files and packages he installed while he’s on the live system across reboots.

The final deliverable will therefore be the ability to have persistent storage on portable media devices on which the Fedora image was put using the Fedora Media Writer on Linux and hopefully (it would be a shame if not) also on Mac and Windows.

Why me

Because I like to work on this project and I know what I need to do. If you think someone else would do a better job than me on this project you shouldn’t pick me.

Or maybe you should pick me because I’m a Programmer Dvorak user who carefully handcrafted his vim configuration. But I guess that doesn’t qualify me.

Rough schedule

Since I’m lazy I won’t mention what’s listed on the GSoC Timeline.

So apart from writing a Blog post every Saturday I do think about using this schedule.

  • 04 - 30 May Do research on persistent storage and read source code of others who implemented it.
  • Until 19 June Implement at least one solution for it on Linux.
  • Until 26 June Improve it based on review so that it can be merged.
  • Until 14 July Port one of the solutions for Linux to Mac and look at which one could be best ported to Windows and how.
  • Until 24 July Improve it based on review so that it can be merged.
  • Until 14 August Implement a solution on Windows and refactor the solutions for the other target systems if need be.
  • Until 21 August Improve it based on review so that it can be merged.

Unavailability

  • 05 - 06 August
  • 29 - 30 August