[Ktechlab-devel] Planning for project meeting on IRC

[Zoltan Padrah]

  Hi,

this will be a long email with information about a meeting that we
should have on IRC. The plan is to discuss on IRC and take decisions,
if they are needed. For efficiency I'm sending this email, so we can
have have discussions in emails, too.

The outline of the email is below:

1. time and date for the meeting
2. status
   - kde4 port, based on kdevplatform
   - conclusions about kdevplatform
   - kde3 version status, code repository
   - webpage and wiki: migration from sourceforge
3. plans
  - minimal usable functionality
  - what to do to have something working
  - sourceforge project: upgrade to Allura
  - future development procedure



1. time and date for the meeting

Because of different timezones (UTC+1 and UTC-4), I'm proposing to
have the meeting sometimes between 18h and 24h in UTC+1 time, which
translates in 13h to 21h at UTC-4 timezone. Please signal the dates
when you have time. On my part almost and date is fine.

Equivalence table:
  UTC+1:  8h 12h 18h 20h 24h
  UTC-4:  3h  8h 13h 15h 21h


2. status
   - kde4 port, based on kdevplatform

The KDE4 port is starting to work. For now running, getting a main
window and creating new circuits should work. If not, there is a bug.
The simulator is being built with Qt4, as a library. I'm currently
working on integrating the GUI with the simulator.
Flowcode is not being worked on at all, currently.

   - conclusions about kdevplatform

The plugin system is not working as well I've expected it. A lot of
time has been wasted by debugging "why the plugin is not loaded?".
Not reimplementing a lot of things is nice, but kdevplatform is having
many releases, and it's becoming complicated to track it.
For now, as the basics are there, and something is finally working, I
would keep working on the kdevplatform-based version until it works
completely.

   - kde3 version status, code repository

Because the KDE3 version is the only working one, we should keep it
working and update it with minor fixes, so ktechlab will be still
usable.
It would be great to test ktechlab on many distributions, in order to
ensure that it runs.

   - webpage and wiki: migration from sourceforge

We are using mediawiki from sourceforge hosted applications. We will
have to migrate from it, because sourceforge is retiring it.
I'm proposing to move to github's wiki, see my previous email.
With this move we also get benefits like: the wiki is under version
control with git; it can be offline edited by using the "gollum"
server, and updated with a git push.


3. plans
  - minimal usable functionality

In my opinion we should have some kind of alpha release pf the kde4
port, as soon as the port will have a minimal set of functionality.
This way we can attract community.
In my opinion a minimal set of functionality is:
- run ktechlab
- create a new circuit
- drag components on the circuit
- the interaction of the components gets simulated
With a few components working, minimal tests could be done.

  - what to do to have something working

What we need to get the minimal usable functionality working:
- integrate the simulator with the gui
- run the simulator
- display the simulation results in the gui


  - sourceforge project: upgrade to Allura

Sourceforge is upgrading its existing interface to a new one, called
Allura. At some point every project has to migrate.
See here:
http://sourceforge.net/p/allura/wiki/Allura%20Wiki/
At some point the ktechlab project will have to migrate, too.
- when to migrate: in my opinion we should migrate after we switched
to github's wiki, with about one month before sf.net is forcing
projects to upgrade ;)
- we should all agree about when to migrate, and who should perform
the migration
For now it's not urgent, but I'd like to have this scheduled.

  - future development procedure

I really like git, and I hope others in the project, too.
I placed this item in the agenda to give an opportunity for discussing
git and github related matters.

 - unit tests and distribution for testing

Most people won't want to compile ktechlab from the source code. It
would be great to provide repositories with packages for most of the
popular distributions.
One option is to use build.opensuse.org. Unfortunately I didn't manage
to write a proper .spec file for ktechlab yet. Help on this would be
great.


Best regards,

 Zoltan