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 <nitul1...@gmail.com> wrote: > > On 29 Oct 2014 13:06, "vedant agarwala" <vedant.k...@gmail.com> wrote: > > > > > > > > On Wed, Oct 29, 2014 at 4:53 AM, Nitul Datt <nitul1...@gmail.com> wrote: > >> > >> Hey! > >> > >> On 10/28/14, vedant agarwala <vedant.k...@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 <nitul1...@gmail.com> > wrote: > >> > > >> >> On 10/27/14, vedant agarwala <vedant.k...@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 < > myr...@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 <nitul1...@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 >
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
