Draft SoK Proposal

[vedant agarwala]

Hello Nitul,

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.

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.

Keep us in the loop through IRC and this mailing list.

Also do the following things:

1. Register a bouncer for IRC (I think KDE's bouncer is called BNC. Look
into it and send a registration request)
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)

Regards,
Vedant.

On Mon, Oct 27, 2014 at 3:50 PM, Myriam Schweingruber <myriam at kde.org>
wrote:

> Hi Nitul,
>
> Thanks for your proposal, but I have some doubts about this.
>
> On Mon, Oct 27, 2014 at 8:47 AM, Nitul Datt <nitul1991 at gmail.com> wrote:
> > Hi!
> One thing which springs to mind is, suppose a user
> > wants to store a custom cover. Should that also be stored in the
> > filesystem mentioned in the specification or should it be stored at
> > the album location itself?
>
> It already does so, why would you change that? Custom covers should
> always be stored locally. Changing what is already there is rarely a
> good idea without a major reason.
>
> Don't forget, you want to add a feature, not remove one :)
>
> On the other hand: why would this specification be needed? AFAICS this
> is a Gnome library, so it would add another dependency, and not a Qt
> one either. I am sure there are far better suited tasks for a SoK
> project than implementing an external specification.
>
> I would need a very compelling reason to implement this, as it is only
> used by Banshee which is hardly a major player. Is it used by other
> media players, specifically Qt-based ones? If not, this is really not
> worth to spend time on IMHO, I would consider this feature request a
> very minor one for the above mentioned reasons.
>
> Also: this is a Junior Job, which is something doable within a week,
> hardly a SoK-worthy task .. I would expect any SoK applicant to
> actually first solve a Junior Job to show their ability to code and
> tackle a larger project like SoK or GSoC. Junior Jobs are classically
> something that can be done within a day or two, a week at most, so
> https://bugs.kde.org/show_bug.cgi?id=296049 is clearly not suitable
> for SoK at all.
>
>
> There are currently two things I would see good SoK tasks:
>
> 1. What is far more needed since quite some time, and what should be a
> high priority to implement is the CUE sheet support. You can easily
> judge that from the number of open bugs and the high number of votes
> for this feature. It is partially implemented, and there is already
> some work lying around IIRC. Mind you, the implementation of proper
> CUE sheet support for files in the collection (CUE sheets already do
> work more or less for tracks not in the collection currently) would
> solve all the existing bugs at once, or at least most of them.
>
> I suggest some digging in other Qt-based players who already do
> implement CUE sheet support which will certainly yield some insight on
> what is done wrong in our code.
>
> 2. Another very much needed feature is porting the current Nepomuk
> support to Baloo: https://bugs.kde.org/show_bug.cgi?id=336380 There
> are links to previous bugs with more information, and the Baloo
> specifications are also very helpful in that regard
>
> And finally: please do not copy-paste bug report wording in your
> proposal, but write your own one! A good proposal would show that you
> have really put some thought into it, not just a tentative timeline to
> something you haven't event really looked at at all. Research is
> starting before you do a proposal, and the results should show in the
> proposal.
>
>
> Regards, Myriam
>
> --
> Proud member of the Amarok and KDE Community
> Protect your freedom and join the Fellowship of FSFE:
> http://www.fsfe.org
> Please don't send me proprietary file formats,
> use ISO standard ODF instead (ISO/IEC 26300)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20141027/e0b50fa3/attachment.html>