gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

On Sat, Aug 13, 2011 at 1:51 PM, Lionel Dricot <ploum@xxxxxxxxx> wrote:

> 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?
>

I second that idea. I think we're not good at releasing from time to time.
Following a time-based release schedule will help us to plan for release and
provide us with some pressure to release at least two versions per year.
(not counting minor release with bug fixes).


> 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?
>

What comes to mind:

* documentation on the wiki: how to develop (already exists:
https://live.gnome.org/gtg/pluginHowTo), where to install
* list of official/third party plugins on the wiki (already exists:
https://live.gnome.org/gtg/plugins)

I don't think we should automate to much the install/remove procedure.
Ideally it should consists in copying a folder in a given directory. Most
other application work that way.

If plugin number grows, then maybe we can consider having a stronger support
for their installation.


>
> 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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-contributors
> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-contributors
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Bertrand Rousseau