Draft SoK Proposal

Tue Oct 28 23:23:34 UTC 2014

Hey!

On 10/28/14, vedant agarwala <vedant.kota at gmail.com> wrote:
> 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 suggested previously I have had a look at the existing code for cue
sheet support. I have also begun looking through the source for qmmp,
a Qt based media player which supports cue sheets. Do you have any
other suggestions?

>>
>> 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)

Done

>> > 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)
>> >
>>

Done. I should get access in a couple of days.

>> 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/
>
>

Lastly, do proposals have to be submitted before the student
application deadline ie 31st October?

>>
>>
>> > 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.
>

--
Regards,
Nitul Datt