Draft SoK Proposal

Nitul Datt nitul1991 at gmail.com
Wed Oct 29 08:14:05 UTC 2014


On 29 Oct 2014 13:06, "vedant agarwala" <vedant.kota at gmail.com> wrote:
>
>
>
> On Wed, Oct 29, 2014 at 4:53 AM, Nitul Datt <nitul1991 at gmail.com> wrote:
>>
>> 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?
>
>
> I haven't done much research but you are going in the right direction-
using existing code.
>>
>>
>> >>
>> >> 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?
>
>
> ask this question on the kde-soc mailing list or IRC. I have no extra
information.

According to Kde-soc, proposals must be submitted before the deadline.

>>
>>
>> >>
>> >>
>> >> > 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
>
>
> Regards,
> Vedant

--
Regards,
Nitul Datt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20141029/8b8fe9ab/attachment.html>


More information about the Amarok-devel mailing list