Fwd: Re: Gambas to Git(Lab)

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Re: Gambas to Git(Lab)

gambas-devel mailing list
Le 22/07/2017 à 20:35, Adrien Prokopowicz a écrit :

> Hello everyone,
>
> In an effort to both switch the Gambas project versioning to Git, and to
> move away
> from Sourceforge, I imported the whole repository to GitLab. You can see
> it here :
>
> https://gitlab.com/prokopyl/gambas
>
>  From what I see, all history, commits, tags and branches have been
> successfully
> imported, and authors have been correctly mapped from their Sourceforge
> usernames to
> Git full names and emails (the SVN/Git mapping file is attached).
>
> I know there has been some GitHub vs. GitLab debate on the mailing list
> somewhere,
> but it didn't seem to have produced anything, so I just picked one.
> Since nothing I have done is GitLab-specific (it's just a plain Git
> repository for now),
> we can easily use GitHub too.
> I personally picked GitLab simply because we can easily retrieve data
> (issues, wiki and such)
> from a generated archive if we ever want to switch, and their integrated
> CI solution
> seems less restricted than Travis (but I didn't go that far with it).
>
> For now, all I did was cloning the entire SVN repo on the server that
> hosts the
> playground (for its symmetric 100Mbit/s connection :) ), then using
> git-svn to
> create a git repo from the clone, and then push it all to GitLab.
>
> I'm currently trying to set up Continuous Integration to generate Ubuntu
> packages, and
> maybe for more distributions later (RHEL/CentOS, Debian, ArchLinux, …).
>
> I know we won't switch to Git right now, I'm at least waiting for 3.10
> to be released
> so everything can calm down. :)
> However I would like your feedback : what do you think is needed to make
> Gambas
> successfully switch to Git ? (Whichever host we end up choosing).
>
> Regards,
>

The problem I encountered when moving from subversion to git in my job
is that git does not really have tags and branches that behave the same
way. I.e. being actual independent trees.

A recently added feature named "working tree" in git seems to help to do
the same thing: developing on different versions at the same time.

Or maybe I didn't understand how to use git for that?

Regards,

--
Benoît Minisini

--
Benoît Minisini

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel
Reply | Threaded
Open this post in threaded view
|

Re: Gambas to Git(Lab)

Adrien Prokopowicz-2
Le Sun, 23 Jul 2017 01:33:09 +0200, Benoît Minisini via Gambas-devel  
<[hidden email]> a écrit:

>
> The problem I encountered when moving from subversion to git in my job  
> is that git does not really have tags and branches that behave the same  
> way. I.e. being actual independent trees.
>
> A recently added feature named "working tree" in git seems to help to do  
> the same thing: developing on different versions at the same time.
>
> Or maybe I didn't understand how to use git for that?
>
> Regards,
>

You can work on different versions/branches at the same time. It's just  
that branches
in Git are waay different from SVN branches. :)

In SVN, both branches and tags do not really exist : they are just separate
directories, and creating a new branch/tag essentially means copying the  
entire
directory over, from /trunk to /branches/3.10 for example.
(SVN actually uses some Copy-on-Write mechanisms under the hood, such as  
hard-links,
but from the user point of view it is just a regular copy).

In Git however, branches are more of a diverged history : they share the  
same history
up to the point where you create the branch, but then the commits you make  
in each
branch are completely separate.
For example, you create a new 3.10 branch from the master (main) branch.  
The commits
you add to the 3.10 branch will not be applied to the master branch, and  
if you switch
back to master, you are in the same state you were before creating the  
branch, and from
there you can add some commits to master (which will not affect 3.10).

You can check out the Git documentation about branches here [0]. It has  
diagrams
and all the commands needed to work with branches. But if you (in the  
broad sense, not
just Benoît) have questions, you can just ask me. :)

What I really like about workflows based on Git branches, is that they  
make it really
easy to start working on new (and unfinished) features without submitting  
them
to the main branch. You simply create a new branch and start working in  
it, allowing
everyone to see your work and provide feedback, without having to include  
it in the
next release.
And when your work is ready, you just merge it back into the main branch.  
:)

A recent example of this would be the gb.term.form component : Fabien  
started working
on it at the time of Gambas 3.9, but just said it is not ready for 3.10.  
If the unfinished
component is in its own branch, then you can just release what is on the  
main branch
without worrying. (This kind of workflow is also explained in the Git  
documentation,
see here[1]).

What makes this workflow even more awesome is the fact than anybody (on  
GitLab/GitHub)
can fork the Gambas repository (i.e. copy the repository into a new one  
they own),
make changes in their repository, and then ask to merge the changes  
through a
Merge Request[2] (GitHub calls these Pull Requests). You can then review  
their
changes, approve them (or not), and merge them.
This is great for allowing one-time contributors to participate without  
having to
give them full permissions on the repository (and it's much better than  
sending
a patch for review). :)

(… and here I made a hundred-page-long message again. Sorry about that,  
but Git
is exciting !)

Regards,

[0]  
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
[1] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
[2] https://docs.gitlab.com/ee/user/project/merge_requests/index.html

--
Adrien Prokopowicz

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Gambas to Git(Lab)

Christof Thalhofer
In reply to this post by gambas-devel mailing list
Am 23.07.2017 um 01:33 schrieb Benoît Minisini via Gambas-devel:

> The problem I encountered when moving from subversion to git in my job
> is that git does not really have tags and branches that behave the same
> way. I.e. being actual independent trees.
>
> A recently added feature named "working tree" in git seems to help to do
> the same thing: developing on different versions at the same time.

I did not use that feature, as I only switch between different branches
in my code (maybe one for each release). But it seems to have advantages
if you have very big repositories (where switching between branches
costs too much time):

https://stackoverflow.com/questions/31935776/what-would-i-use-git-worktree-for

> Or maybe I didn't understand how to use git for that?

Here is a good explanation of common git workflows:
https://www.atlassian.com/git/tutorials/comparing-workflows

Why do you want to develop in different versions at the same time, to
fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
what you wanted to do?

I am unsure what sort of development workflow would be the best for Gambas.

If I look at a big projekt for example that put its codebase to Git –
OTRS – they did it so:

https://github.com/OTRS/otrs

Look there at the branches and tags. They seem to have ongoing
development in master with branches for the "big" releases. Tags are
used to point to subreleases.


Alles Gute

Christof Thalhofer

--
Dies ist keine Signatur


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gambas to Git(Lab)

Christof Thalhofer
In reply to this post by Adrien Prokopowicz-2
Am 23.07.2017 um 04:01 schrieb Adrien Prokopowicz:

> but Git
> is exciting !)

Yes! Full Ack!
:-)

I love to work with Git. It makes the horizont so much wider.


Alles Gute

Christof Thalhofer

--
Dies ist keine Signatur


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Gambas to Git(Lab)

PICCORO McKAY Lenz
In reply to this post by gambas-devel mailing list
git have REAL branchs and tas.. SVN do just copy's, also SVN its centraliced a problem in team collaborations , due the fusion of resulting jobs comes in many deadlocks at the developer side.. of course at the server central side are very easy to mantain.. but we must see the horizont

i'm not avocate of "up to date things" but in this way are really need.. also the SF interface are so slower when i goin to the cybercafe.. due i'm not have internet access at my home..

so in many ways the SVN (and for me that the most important part) can work offline.. SVN need connection alive to mark commits... its very tedious for me use SVN due i not have internet connection.. so  that the mayor problem.. the very centralised behavior that git does are more flexible!
 
Date: Sun, 23 Jul 2017 01:33:09 +0200
From: Beno?t Minisini <[hidden email]>
The problem I encountered when moving from subversion to git in my job
is that git does not really have tags and branches that behave the same
way. I.e. being actual independent trees.

A recently added feature named "working tree" in git seems to help to do
the same thing: developing on different versions at the same time.

Or maybe I didn't understand how to use git for that?

Regards,

--
Beno?t Minisini

--
Beno?t Minisini



------------------------------

Message: 3
Date: Sun, 23 Jul 2017 04:01:04 +0200
From: "Adrien Prokopowicz" <[hidden email]>
To: "mailing list for gambas developers"
        <[hidden email]>
Subject: Re: [Gambas-devel] Gambas to Git(Lab)
Message-ID: <op.y3s3v2cwdlsaci@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes

Le Sun, 23 Jul 2017 01:33:09 +0200, Beno?t Minisini via Gambas-devel
<[hidden email]> a ?crit:
>
> The problem I encountered when moving from subversion to git in my job
> is that git does not really have tags and branches that behave the same
> way. I.e. being actual independent trees.
>
> A recently added feature named "working tree" in git seems to help to do
> the same thing: developing on different versions at the same time.
>
> Or maybe I didn't understand how to use git for that?
>
> Regards,
>

You can work on different versions/branches at the same time. It's just
that branches
in Git are waay different from SVN branches. :)

In SVN, both branches and tags do not really exist : they are just separate
directories, and creating a new branch/tag essentially means copying the
entire
directory over, from /trunk to /branches/3.10 for example.
(SVN actually uses some Copy-on-Write mechanisms under the hood, such as
hard-links,
but from the user point of view it is just a regular copy).

In Git however, branches are more of a diverged history : they share the
same history
up to the point where you create the branch, but then the commits you make
in each
branch are completely separate.
For example, you create a new 3.10 branch from the master (main) branch.
The commits
you add to the 3.10 branch will not be applied to the master branch, and
if you switch
back to master, you are in the same state you were before creating the
branch, and from
there you can add some commits to master (which will not affect 3.10).

You can check out the Git documentation about branches here [0]. It has
diagrams
and all the commands needed to work with branches. But if you (in the
broad sense, not
just Beno?t) have questions, you can just ask me. :)

What I really like about workflows based on Git branches, is that they
make it really
easy to start working on new (and unfinished) features without submitting
them
to the main branch. You simply create a new branch and start working in
it, allowing
everyone to see your work and provide feedback, without having to include
it in the
next release.
And when your work is ready, you just merge it back into the main branch.
:)

A recent example of this would be the gb.term.form component : Fabien
started working
on it at the time of Gambas 3.9, but just said it is not ready for 3.10.
If the unfinished
component is in its own branch, then you can just release what is on the
main branch
without worrying. (This kind of workflow is also explained in the Git
documentation,
see here[1]).

What makes this workflow even more awesome is the fact than anybody (on
GitLab/GitHub)
can fork the Gambas repository (i.e. copy the repository into a new one
they own),
make changes in their repository, and then ask to merge the changes
through a
Merge Request[2] (GitHub calls these Pull Requests). You can then review
their
changes, approve them (or not), and merge them.
This is great for allowing one-time contributors to participate without
having to
give them full permissions on the repository (and it's much better than
sending
a patch for review). :)

(? and here I made a hundred-page-long message again. Sorry about that,
but Git
is exciting !)

Regards,

[0]
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
[1] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
[2] https://docs.gitlab.com/ee/user/project/merge_requests/index.html

--
Adrien Prokopowicz



------------------------------

Message: 4
Date: Sun, 23 Jul 2017 12:02:30 +0200
From: Christof Thalhofer <[hidden email]>
To: mailing list for gambas developers
        <[hidden email]>
Subject: Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Am 23.07.2017 um 01:33 schrieb Beno?t Minisini via Gambas-devel:

> The problem I encountered when moving from subversion to git in my job
> is that git does not really have tags and branches that behave the same
> way. I.e. being actual independent trees.
>
> A recently added feature named "working tree" in git seems to help to do
> the same thing: developing on different versions at the same time.

I did not use that feature, as I only switch between different branches
in my code (maybe one for each release). But it seems to have advantages
if you have very big repositories (where switching between branches
costs too much time):

https://stackoverflow.com/questions/31935776/what-would-i-use-git-worktree-for

> Or maybe I didn't understand how to use git for that?

Here is a good explanation of common git workflows:
https://www.atlassian.com/git/tutorials/comparing-workflows

Why do you want to develop in different versions at the same time, to
fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
what you wanted to do?

I am unsure what sort of development workflow would be the best for Gambas.

If I look at a big projekt for example that put its codebase to Git ?
OTRS ? they did it so:

https://github.com/OTRS/otrs

Look there at the branches and tags. They seem to have ongoing
development in master with branches for the "big" releases. Tags are
used to point to subreleases.


Alles Gute

Christof Thalhofer

--
Dies ist keine Signatur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature

------------------------------

Message: 5
Date: Sun, 23 Jul 2017 12:03:45 +0200
From: Christof Thalhofer <[hidden email]>
To: mailing list for gambas developers
        <[hidden email]>
Subject: Re: [Gambas-devel] Gambas to Git(Lab)
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Am 23.07.2017 um 04:01 schrieb Adrien Prokopowicz:

> but Git
> is exciting !)

Yes! Full Ack!
:-)

I love to work with Git. It makes the horizont so much wider.


Alles Gute

Christof Thalhofer

--
Dies ist keine Signatur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature

------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

------------------------------

Subject: Digest Footer

_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel


------------------------------

End of Gambas-devel Digest, Vol 112, Issue 3
********************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Gambas to Git(Lab)

Adrien Prokopowicz-2
In reply to this post by Christof Thalhofer
Le Sun, 23 Jul 2017 12:02:30 +0200, Christof Thalhofer  
<[hidden email]> a écrit:

> Here is a good explanation of common git workflows:
> https://www.atlassian.com/git/tutorials/comparing-workflows
>
> Why do you want to develop in different versions at the same time, to
> fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
> what you wanted to do?
>
> I am unsure what sort of development workflow would be the best for  
> Gambas.
>
> If I look at a big projekt for example that put its codebase to Git –
> OTRS – they did it so:
>
> https://github.com/OTRS/otrs
>
> Look there at the branches and tags. They seem to have ongoing
> development in master with branches for the "big" releases. Tags are
> used to point to subreleases.
>
>
> Alles Gute
>
> Christof Thalhofer

I took a bit of time to think about it, and I think the best workflow for
developing Gambas would be the one that's described in the Git  
documentation[0] :

- The master branch is the stable branch : it only contains the latest  
stable
   release of gambas. (with tags to keep the previous releases).
- A dev branch, for the development version. (the equivalent of the  
current trunk).
- Various branches for work-in-progress features that are not ready at all  
(like gb.term.form)

This way, we keep a workflow similar to the current one for bug fixes &  
minor changes
(we just commit to the dev branch).
For bigger changes and experimental components we create a new branch from  
the dev branch,
work on it, and then merge it back in the development branch when it's  
ready.
And when we want to release a new Gambas version, we just merge the  
development branch
in master, and create a tag to mark the new release.

If we need to make a patch release for bugfixes in the meantime, we can  
just use the master
branch to get back to the latest stable, and then make the fixes from  
there.
If the fix is already done on the development version, we can cherry-pick  
it from the dev
branch, and otherwise we can just make the fix on master (or on a  
temporary branch), and
then merge master back into the development branch.

This is also the workflow I use at work so maybe I'm too used to it and  
don't see
the downsides, but to me it seems to cover all of the use-cases.

[0] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

--
Adrien Prokopowicz

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Gambas to Git(Lab)

Christof Thalhofer
Hi,

Am 28.07.2017 um 16:35 schrieb Adrien Prokopowicz:

> If we need to make a patch release for bugfixes in the meantime, we can  
> just use the master
> branch to get back to the latest stable, and then make the fixes from  
> there.
> If the fix is already done on the development version, we can cherry-pick  
> it from the dev
> branch, and otherwise we can just make the fix on master (or on a  
> temporary branch), and
> then merge master back into the development branch.
>
> This is also the workflow I use at work so maybe I'm too used to it and  
> don't see
> the downsides, but to me it seems to cover all of the use-cases.
>
> [0] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
Assume, Gambas gets bigger and more important and somewhere in the
future there exists a Gambas 3.20 in old distributions like Debian and
Gambas 4.05 in current Ubuntu, each of these versions is "stable".

Assume also there is a security breach introduced in Gambas 3.10 ;-)

How would you insert a hotfix which would lead to stable 3.21 and stable
4.06 in your model? IMO ... that would be impossible.


Alles Gute

Christof Thalhofer

--
Dies ist keine Signatur


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Gambas to Git(Lab)

Adrien Prokopowicz-2
Le Fri, 28 Jul 2017 17:06:41 +0200, Christof Thalhofer  
<[hidden email]> a écrit:

> Hi,
>
> Assume, Gambas gets bigger and more important and somewhere in the
> future there exists a Gambas 3.20 in old distributions like Debian and
> Gambas 4.05 in current Ubuntu, each of these versions is "stable".
>
> Assume also there is a security breach introduced in Gambas 3.10 ;-)
>
> How would you insert a hotfix which would lead to stable 3.21 and stable
> 4.06 in your model? IMO ... that would be impossible.
>
>
> Alles Gute
>
> Christof Thalhofer
>

You're right, I mistakingly assumed we would only have to maintain one  
stable
version (as it is the case right now).

However, I think the fix is pretty simple : we could add a legacy branch  
(branched
right before the 4.0 version would be merged into master, so it is still  
3.20), and
commit the fixes for the legacy version into it when needed (so we can  
release both
versions in parallel).

If the fix can be applied to both the legacy and stable versions without  
rewriting it
(unlikely, since the codebase would change a lot between these versions),  
then
cherry-picking the fixing commit into master should be enough. :-)

The model isn't set it stone. It's still Git, we can do whatever we want
whenever we want. Adding a few branches to our workflow later isn't a  
problem. ;-)

--
Adrien Prokopowicz

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Gambas to Git(Lab)

Christof Thalhofer
Am 28.07.2017 um 17:38 schrieb Adrien Prokopowicz:

> You're right, I mistakingly assumed we would only have to maintain one  
> stable
> version (as it is the case right now).
>
> However, I think the fix is pretty simple : we could add a legacy branch  
> (branched
> right before the 4.0 version would be merged into master, so it is still  
> 3.20), and
> commit the fixes for the legacy version into it when needed (so we can  
> release both
> versions in parallel).
Yes. Ok, I see, so:

                               .--------------.
                             ^ | Branch: 3.21 |----->
                            /  '--------------'
.--------.      .-----------.                 .-----------.
| Master |----->| Tag: 3.20 |------......---->| Tag: 4.05 |
'--------'      '-----------'                 '-----------'

Right?

> If the fix can be applied to both the legacy and stable versions without  
> rewriting it
> (unlikely, since the codebase would change a lot between these versions),  
> then
> cherry-picking the fixing commit into master should be enough. :-)

Yes.

> The model isn't set it stone. It's still Git, we can do whatever we want
> whenever we want. Adding a few branches to our workflow later isn't a  
> problem. ;-)

Also Yes :-)


Alles Gute

Christof Thalhofer

--
Dies ist keine Signatur


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Re: Gambas to Git(Lab)

Adrien Prokopowicz-2
Le Fri, 28 Jul 2017 22:11:10 +0200, Christof Thalhofer  
<[hidden email]> a écrit:

> Am 28.07.2017 um 17:38 schrieb Adrien Prokopowicz:
>
>> You're right, I mistakingly assumed we would only have to maintain one
>> stable
>> version (as it is the case right now).
>>
>> However, I think the fix is pretty simple : we could add a legacy branch
>> (branched
>> right before the 4.0 version would be merged into master, so it is still
>> 3.20), and
>> commit the fixes for the legacy version into it when needed (so we can
>> release both
>> versions in parallel).
>
> Yes. Ok, I see, so:
>
>                                .--------------.
>                              ^ | Branch: 3.21 |----->
>                             /  '--------------'
> .--------.      .-----------.                 .-----------.
> | Master |----->| Tag: 3.20 |------......---->| Tag: 4.05 |
> '--------'      '-----------'                 '-----------'
>
> Right?

Yes, that's exactly it. :)

--
Adrien Prokopowicz

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel