Draft SoK Proposal

Wed Oct 29 08:49:01 UTC 2014

Then do that.

When you post a draft proposal on the mailing list post the entire text as
plain text rather than a link to a doc. Easier to read and comment in line.

Regards,
Vedant.

On Wed, Oct 29, 2014 at 1:44 PM, Nitul Datt <nitul1991 at gmail.com> wrote:

>
> 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/da486052/attachment-0001.html>