<div dir="ltr">Hello Nitul,<div><br></div><div>I agree with all that Myriam has said. I should've waited for a go-ahead for a senior Amarok member; if you remember I had mentioned that I was unable to get in touch with them. Sorry for rushing in and making you do some extra work.</div><div><br></div><div>Take your time and pick a new project from the 2 mentioned. AFAIK there is no "start" date for SoK but an end date (31st January). A proposal is as important as the coding itself so it is perfectly fine to spend time on it.</div><div><br></div><div>Keep us in the loop through IRC and this mailing list.</div><div><br></div><div>Also do the following things:</div><div><br></div><div>1. Register a bouncer for IRC (I think KDE's bouncer is called BNC. Look into it and send a registration request)</div><div>2. Register for a developer account and set up a personal scratch git repository (but even then you will have to upload code to reviewboard, as it is easier to review there)</div><div><br></div><div>Regards,</div><div>Vedant.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 27, 2014 at 3:50 PM, Myriam Schweingruber <span dir="ltr"><<a href="mailto:myriam@kde.org" target="_blank">myriam@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nitul,<br>
<br>
Thanks for your proposal, but I have some doubts about this.<br>
<br>
On Mon, Oct 27, 2014 at 8:47 AM, Nitul Datt <<a href="mailto:nitul1991@gmail.com">nitul1991@gmail.com</a>> wrote:<br>
> Hi!<br>
<span class="">One thing which springs to mind is, suppose a user<br>
> wants to store a custom cover. Should that also be stored in the<br>
> filesystem mentioned in the specification or should it be stored at<br>
> the album location itself?<br>
<br>
</span>It already does so, why would you change that? Custom covers should<br>
always be stored locally. Changing what is already there is rarely a<br>
good idea without a major reason.<br>
<br>
Don't forget, you want to add a feature, not remove one :)<br>
<br>
On the other hand: why would this specification be needed? AFAICS this<br>
is a Gnome library, so it would add another dependency, and not a Qt<br>
one either. I am sure there are far better suited tasks for a SoK<br>
project than implementing an external specification.<br>
<br>
I would need a very compelling reason to implement this, as it is only<br>
used by Banshee which is hardly a major player. Is it used by other<br>
media players, specifically Qt-based ones? If not, this is really not<br>
worth to spend time on IMHO, I would consider this feature request a<br>
very minor one for the above mentioned reasons.<br>
<br>
Also: this is a Junior Job, which is something doable within a week,<br>
hardly a SoK-worthy task .. I would expect any SoK applicant to<br>
actually first solve a Junior Job to show their ability to code and<br>
tackle a larger project like SoK or GSoC. Junior Jobs are classically<br>
something that can be done within a day or two, a week at most, so<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=296049" target="_blank">https://bugs.kde.org/show_bug.cgi?id=296049</a> is clearly not suitable<br>
for SoK at all.<br>
<br>
<br>
There are currently two things I would see good SoK tasks:<br>
<br>
1. What is far more needed since quite some time, and what should be a<br>
high priority to implement is the CUE sheet support. You can easily<br>
judge that from the number of open bugs and the high number of votes<br>
for this feature. It is partially implemented, and there is already<br>
some work lying around IIRC. Mind you, the implementation of proper<br>
CUE sheet support for files in the collection (CUE sheets already do<br>
work more or less for tracks not in the collection currently) would<br>
solve all the existing bugs at once, or at least most of them.<br>
<br>
I suggest some digging in other Qt-based players who already do<br>
implement CUE sheet support which will certainly yield some insight on<br>
what is done wrong in our code.<br>
<br>
2. Another very much needed feature is porting the current Nepomuk<br>
support to Baloo: <a href="https://bugs.kde.org/show_bug.cgi?id=336380" target="_blank">https://bugs.kde.org/show_bug.cgi?id=336380</a> There<br>
are links to previous bugs with more information, and the Baloo<br>
specifications are also very helpful in that regard<br>
<br>
And finally: please do not copy-paste bug report wording in your<br>
proposal, but write your own one! A good proposal would show that you<br>
have really put some thought into it, not just a tentative timeline to<br>
something you haven't event really looked at at all. Research is<br>
starting before you do a proposal, and the results should show in the<br>
proposal.<br>
<br>
<br>
Regards, Myriam<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Proud member of the Amarok and KDE Community<br>
Protect your freedom and join the Fellowship of FSFE:<br>
<a href="http://www.fsfe.org" target="_blank">http://www.fsfe.org</a><br>
Please don't send me proprietary file formats,<br>
use ISO standard ODF instead (ISO/IEC 26300)<br>
</font></span></blockquote></div><br></div>