On 12. 4. 2013 Edward Toroshchin wrote:
> On Tue, Apr 09, 2013 at 03:46:31PM +0200, Matěj Laitl wrote:
> > I've added 3 ideas, but I might not be able to mentor them in case I'm
> > accepted as a student, however I plan to do code reviews. Please have a
> > look at these - if they seem nonsense, please shout early! "I could
> > mentor this" or "I suggest a change" are of course also accepted. ;)
>
> They look quite good to me: well described and timely. For which one are
> you going to apply yourself?
For "MTP Collection Rewrite with Emphasis on Android Device Support" (with
secondary goal to get rid of the MediaDevice framework) - yeah, not listed - I
thought it would be fairer than letting a newcomer compete on the same idea as
me. (see also my February mail to amarok private ML)
> I belive I would be able to mentor either of the projects.
Great!
> I didn't read into the details, though, I think we should do it together
> with the students who want to apply. Those are ideas, after all, not
> thorough project specs.
Right, I might have been too detailed sometimes. (OTOH, there are some goals
that I think we should be strict about)
> > I have also another idea on my mind: Scripting Interface Revival
>
> Why revival? It's alive and kicking.
Yeah "revival" is a bad word. Please suggest a better name, I'm unable to
think of any.
> Still, this is a nice idea, but the project should start with a review
> of existing scripts, API calls they use and don't use, probably contact
> some of the script authors and ask what they like/dislike/want/don't
> want (hey, script writers, are you reading this?).
Okay, I'll try to formulate these as an idea.
> > Myriam also suggests that we should run the "QML Context View" idea again
> > and I support it. Agreed?
>
> No objection from me, but I don't think I'll be up to mentoring that.
Right, no point advertising that if we won't find a mentor. Teo? Bart?
> I've also got an ambitious idea for the brave-hearted: a design of
> Amarok 3 architecture. One should read carefully the Randa doc (scope,
> vision, requirements), our codebase, and come up with the following:
Well, while I agree something like this is needed and beneficial, I fear this
is not really well suited for a newcomer. :-( Things to remember from past is
AFAIK that GSoC projects end up harder than expected.
[the technical suggestions below are however interesting, I'll reply in a
separate mail to split threads about GSoC and architecture]
Matěj
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
