Draft SoK Proposal

Mon Oct 27 19:32:23 UTC 2014

Hello Nitul,

Seems like you forgot to "reply to all" (as amarok-devel was not in your
recipients).

On Tue, Oct 28, 2014 at 12:37 AM, Nitul Datt <nitul1991 at gmail.com> wrote:

> On 10/27/14, vedant agarwala <vedant.kota at gmail.com> wrote:
> > 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.
> >
>
> That's quite alright. Although this leaves me with only a few days
> until October 31st, the student aplication deadline.
>
> > 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.
> >
>
> Well I checked and the only possibility left is implementing Cue sheet
> support. Vishesh Handa just clarified about the port from nepomuk to
> baloo on the buglist. His suggested solution will take one or two days
> maximum.
> I had just mailed the first draft of the proposal. I knew it required
> a lot of work.
> I just have one question, the SoK page mentions that the student
> application deadline is 31st October. Does one have to submit a
> proposal before then? The FAQ mentions that it is not necessary to
> submit a proposal before applying.
>

If this is the case you should apply asap and work on your proposal.

>
> As for implementing cue sheet support, I have no idea regarding this
> and would require a little bit of help from your side.
>

I can help on how to go about it but a proposal has to made entirely by
you. See the bugs relevant to the idea and try to fix as many of them as
possible, if not all. (include references to them in your proposal). Come
up with an idea and google each step. If you have doubts in selecting a
particular path we can help as you are not yet fully familiar with Amarok's
coding guidelines.
Beware of not reinventing the wheel- if there is code that is relevant,
just copy it. If a library fits your needs we can include it during the
Amarok build (though try to minimize this).

>
> > 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)
> >
>
> I can only access freenode webchat from my university wifi.
>

You did not get what I meant. With a frown I give you the links:
https://community.kde.org/Sysadmin/BNC, https://bnc.kde.org:7778/

>
>
> > 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)
> >>
> >
>
>
> --
> Regards,
> Nitul Datt
>

Break a leg.

Regards,
Vedant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20141028/b3d42313/attachment.html>