[Kstars-devel] KStars' GSoC

[Akarsh Simha]

Hi

This is a summary, from my memory, of yesterday's IRC assembly:

Regarding the direction KStar development should head in:
=========================================================

There are still some questions regarding the direction of KStars, that
had debated answers:

1. Should we work on exploiting the Open GL backend more by adding
   features?

   While Med feels that we should do this, my take on this is that
   while polishing the OpenGL backend and making it bug-free is indeed
   of importance, adding features to the OpenGL backend at the moment
   is probably not a good idea, until we fork out the computational
   engine from the rest of the code.

Here are some consensus that we reached:

1. Should we consider sharing code-base with other astronomy software?
   Stellarium will be the first candidate, because both KStars and
   Stellarium are written on Qt.

   Some point out that this has already been tried in the past and
   have not led to tangible results. My take on this is that it's
   probably not the right time to do so, and we should get our
   codebase in shape before we start talking to other software teams.

2. We agreed that splitting the code-base into a 3-tier architecture
   was a good idea.

3. The majority consensus tended towards making the computation and
   data engines libraries, rather than servers. The consensus seemed
   to indicate that a server-client architecture (computation server +
   data server + client that uses these to display a sky map) for
   KStars was overkill, at least at the moment.

I don't recall any more. Please add if you do.

Regarding GSoC:
===============

Based on inputs from various people, we came up with four GSoC
projects, which are listed here:

http://community.kde.org/GSoC/2011/Ideas#KDE_Edu

While some of us wanted to concentrate on re-architecturing the
code-base, some of us wanted GSoCs with practical and
end-user-appreciable results. So we decided to have a mix of
both. 

There are still problems to solve and things to consider (these are
things that I consider problems. Please feel free to share your
opinions, and also feel free to add issues I've overlooked):

1. While printing is largely independent of major changes in our code
   organization, the other two might not decouple very well from the
   code that's touched by the code-restructuring project. This is
   something to still be thought about. Maybe they will just be
   affected to a small extent. At least, we should try to ensure that
   as much as we can.

2. It is doubtful as to whether we will have students good enough to
   handle the task of restructuring the code-base. We need to
   deliniate that project with as much detail as possible, so that we
   can firstly decide whether this is a tangible GSoC project, and if
   it is, we can guide the student very efficiently, giving him/her a
   clear direction. Even if it is not going to be a GSoC project,
   doing this will help us developers do this later. I think we should
   try to make it into as many bite-sized pieces as possible.

3. We need to add detail to many of the projects. I will open threads
   here for each project and put in my TODOs as promised, and others
   can put in their TODOs and write out solutions as well.

4. More projects are always welcome. The more projects we have on the
   ideas page, the more good proposals we get, so chances are higher
   that we will get enough slots to saturate our mentoring capacity.

This year, Victor and I have agreed to mentor, with us load-sharing
all the projects, so that one of us can assist when the other is not
free. Any more mentors are welcome! Prakash said he might be able to
mentor this year too, and he will let us know in March.

Regards
Akarsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20110213/e885c4c9/attachment.sig