gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

Hello,

Let's talk a bit about GTG's future.

GTG 0.2.9 is intended to be released on Aug. 22nd. This will be an
unstable release, mainly intended for testing.

GTG 0.3 should come next without any major feature, only stabilization.
(possible exception: the search feature).

Starting with 0.2.9 release, the plan is to keep an "always releasable
trunk", something we sucked at (at it is mainly my fault). Work will
happen in branches, as it should be.

After that, we will try to release often: 0.3.1, 0.3.2, etc. Maybe we
could follow the GNOME release schedule?


Challenges:
* * * * * *

1) Currently, liblarch is still committed to GTG's trunk (although we
already have a separate VCS for it: https://gitorious.org/liblarch/ ).
The plan is to make liblarch completely independent. That way, GTG could
always use the "stable" liblarch and not being affected by work
happening on liblarch (which will be mainly optimization work).

But we need to keep it easy for people to try the latest GTG trunk. My
plan is to automatically detect that there's is a "liblarch" folder next
to your GTG's folder and use that. That way, debugging GTG would only
require :
git clone https://git.gitorious.org/liblarch/liblarch.git
bzr branch lp:gtg

This should be quite easy to implement, contribution for this are
welcome.

We will also need to package liblarch in our PPA. Luca Falavigna, are
you still willing to help us with this?


2) plugins et backends.

We start to have many plugins and backends. They have their own bug,
they often break. For exemple, the RTM backend currently take half of
our bugtracker.

We should have only a handful of blessed plugins/backends that will be
maintained in our trunk. Those will be officially supported.

But, for all the others, there should be separate projects, which
doesn't affect our trunk.

The problem here is: how to allow people to easily install/remove
plugins which are not from our trunk? What is the needed infrastructure?

Any ideas are welcome.


3) Future developments. 

After that, we will attack future projects. I foresee:
- rewrite of the task editor (to solve some bugs and allow dynamic
update of the content)
- porting to GTK3
- integration with other software (including drag-n-drop)

On liblarch side:
- heavy optimisation 
- maybe porting liblarch to C?


Thanks for reading,

Lionel