GSoC application review - reimplementing personal metadata importers

Sat Apr 20 14:57:20 UTC 2013

Hi fellow developers,

I want to participate in Google Summer of Code; I don't have much time
in the coming week, and didn't have much in the past few weeks, so I
can't prepare many applications. But I at least want to make sure that
the one I send is of proper quality, therefore I humbly request that
you review my application below, and let me know where it's lacking,
where it has too much, and where it's unclear. Thanks!

There are a few things that I could add, but I didn't think they're
relevant enough. For example I have experience with Boost, and
submitted a bug report recently with a proposed fix, which was
promptly integrated into upstream. On the one hand that's experience
with developing and open source, on the other hand Amarok has nothing
to do with Boost. Should I add that? (I know that one bug report isn't
too impressive, but I'm just starting in the open source community.
I'm hoping that GSoC will get me far in that regard.)

Following is my application:

Name: Konrad Zemek
Email Address: konrad.zemek at gmail.com
Freenode IRC Nick: kzemek
IM Service and Username: Skype, handle: konrad-kun
Location: Kraków, Poland. GMT+2 during the Summer.

Proposal Title:
	Reimplement Amarok 1.4/iTunes import on top of Statistics
	Synchronization, and new Amarok 2.x	and Rhythmbox as synchronization
	targets.

Motivation for Proposal / Goal:
	Currently, Amarok has the ability to sync personal track metadata
	with Amarok 1.4 and iTunes databases. Although this code still
	fulfills its purpose, the StatSyncing framework has since been added
	to the codebase, and serves as a perfect base for a rewrite of
	importers. Perhaps the most significant advantage implementation
	on top of StatSyncing offers over the current one, is the ability
	to resynchronize information and to work with collections other
	than local.
	Still, synchronization with Amarok 1.4 and iTunes covers only
	a small portion of users that may be willing to use Amarok 2.x,
	but because of the consequences of losing their personal metadata,
	are tied to their current music player. To alleviate this, I intend
	to add Rhythmbox as a new target for synchronization. Rhythmbox
	it the default GNOME's music player, and since Ubuntu 12.04, the
	music player shipped by default in Ubuntu. I feel that this is an
	important target for metadata synchronization, easing not only the
	transition between music players, but between whole desktop
	environments - GNOME and KDE.
	To complete the set, synchronization with Amarok 2.x will be added,
	so that user can synchronize his personal track metadata between
	separate Amarok databases.

Implementation Details:
	This project breaks up in a few parts with well-defined deliverables
	(details about timeline are in Tentative Timeline section).

	* Importer tests
		There are either no tests for importing in the current trunk,
		or they are in a wrong place. Regardless, since a big part of
		this project consists of refactoring, I will have to prepare
		a quality suite of tests to make sure that I introduce no
		regressions.

		- Review current importer tests (if any)
		- Implement whole test suite using QTest and gmock best
		practices
		- The main test cases would involve using a dummy input,
		invoking importer and verifying collection.
		- For best test results, at least the collection class may
		be mocked

	* Reimplementing importers
		- Reimplement importers to use StatSyncing
		- Data-reading modules, after needed changes, would become track
		providers
		- Current services using StatSyncing framework will be used
		as a reference (primarily last.fm service)
		- Clean-up the code responsible for data-reading
		- At each step where the code is functional (at least between
		reimplementing FastForwardImporter and ITunesImporter),
		supplement the tests so that new capabilities are accounted for
		(e.g. make sure that foreign playcounts are not simply stacked
		on locally saved playcounts with each synchronization)
		- The importer code may prove to be repeatable (in the extreme
		case the only thing differing these importers will be their
		respective parsers); this code will be deduplicated. If it fits
		DatabaseImporter (a parent class for importers) responsibilities
		then the code should land in DatabaseImporter implementation,
		otherwise I will introduce new helper classes.

	* Implement Rhythmbox and Amarok 2.x importers
		Rhythmbox stores its personal metadata in an XML file, which
		should be easy to read through QXml SAX parser. When in doubt
		about the format, I will consult Rhythmbox source code.

		- Rhythmbox parser shall be robust, that is it shouldn't depend
		on the order of information (this is obvious, but important)
		- At this point both Amarok 1.4 and iTunes importers are
		rewritten, so their implementations will be used as a reference
		for Amarok 2.x and Rhythmbox importers.
		- The subgoal is to make sure that adding additional import
		targets is straightforward and easy, and if possible doesn't
		introduce code duplication.
		- As with reimplementing importers, every piece of working code
		should be tested to ensure that it is performing correctly,
		and so that regressions don't occur in the future.

Tentative Timeline:
	June 17 - 23:
		Investigating tests and drafting up test cases
	June 24 - 30:
		Investigating tests and drafting up test cases (exam week)
	July 01 - 07:
		Preparing the test suite
	July 08 - 14:
		Implementing the test cases
	July 15 - 21:
		Reimplementing FastForward importer
	July 22 - 28:
		Reimplementing FastForward importer / iTunes importer
	July 29 - August 04:
		Reimplementing iTunes importer
	August 05 - 11:
		Implementing test cases for new functionality
	August 12 - 18:
		In-depth research of Rhythmbox metadata format
	August 19 - 25:
		Implementing Rhythmbox importer
	August 26 - September 01:
		Implementing Rhythmbox importer / Amarok 2.x importer
	September 02 - 08:
		Implementing Amarok 2.x importer
	September 09 - 15:
		Implementing test cases for new importers
	September 16 - 22:
		fix bugs, QA
	September 23 - 29:
		fix bugs, QA

Obligations from late May to early August:
	I have school until the very early July, with exams starting the
	last week of June. I will be putting my work on hold for the whole
	period of Google Summer of Code, but up until early June I may still
	be required to commit at least a few hours a week to my current job.
	So from early June to late September I have no commitments except
	for school, and from early July to late September no commitments
	at all.

About me:
	I'm a student at AGH University of Technology, Kraków, Poland.
	I study Computer Science, and I'm currently in my second year.
	At the moment I'm employed as a part time C++ programmer at
	X-Formation [1], Poland, where my work ranges from conducting
	interviews with potential employees, through refactoring and
	bugfixing to implementing new features for our product.

	I'm a big fan of open source, and KDE in general. I've used Amarok
	a lot and not only read the source, but contributed to it [2].
	I am also familiar with Qt framework and have used it to prototype
	several small applications. I'm an early adopter, and my fiddling
	with Qt 5 beta has led me to uncover an important bug [3].

	I'm very skilled in C++. Other than that I program mainly in Scala,
	and Java when required (and my university requires that a lot).
	I'm experienced with test driven development, continuous
	integration, code reviews and other agile techniques.

	If my application is accepted, I am going to commit my full time to
	complete the project, including putting my job on hold for the
	duration of GSoC. I expect to be working 40 hours a week. I am
	comfortable with working independently under a supervisor living
	on the other side of the globe. Although I have not have worked
	in this style before, I foresee no problems with this and can even
	change my working hours if needed. I think that code reviews
	and email contact are the best way of tracking progress in this
	case. I am fluent in English, so communication should be a problem.
	Of course I would work as well with a local mentor, with whom
	I could discuss issues over a coffee.

	During the bonding period I expect to complete some more tasks for
	Amarok, possibly continuing what I started with [2] (in review
	comments I mentioned streamlining track sorting and making it
	consistent across the source code).

Junior job link:
	[2]

References:
[1] http://www.x-formation.com/
[2] https://git.reviewboard.kde.org/r/110070/
[3] https://bugreports.qt-project.org/browse/QTBUG-26832