gambas-devel Mailing List for Gambas (Page 4)
Brought to you by:
gambas
This list is closed, nobody may subscribe to it.
2003 |
Jan
(8) |
Feb
(17) |
Mar
(10) |
Apr
(19) |
May
(39) |
Jun
(82) |
Jul
(12) |
Aug
(21) |
Sep
(50) |
Oct
(21) |
Nov
(45) |
Dec
(42) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(83) |
Feb
(58) |
Mar
(18) |
Apr
(63) |
May
(33) |
Jun
(36) |
Jul
(42) |
Aug
(154) |
Sep
(90) |
Oct
(117) |
Nov
(120) |
Dec
(73) |
2005 |
Jan
(231) |
Feb
(117) |
Mar
(157) |
Apr
(94) |
May
(42) |
Jun
(41) |
Jul
(62) |
Aug
(75) |
Sep
(46) |
Oct
(72) |
Nov
(74) |
Dec
(25) |
2006 |
Jan
(34) |
Feb
(18) |
Mar
(84) |
Apr
(40) |
May
(19) |
Jun
(43) |
Jul
(59) |
Aug
(101) |
Sep
(123) |
Oct
(49) |
Nov
(80) |
Dec
(18) |
2007 |
Jan
(28) |
Feb
|
Mar
(1) |
Apr
(25) |
May
(11) |
Jun
(8) |
Jul
(9) |
Aug
(12) |
Sep
(13) |
Oct
(17) |
Nov
(73) |
Dec
(15) |
2008 |
Jan
(108) |
Feb
(34) |
Mar
(112) |
Apr
(82) |
May
(56) |
Jun
(74) |
Jul
(31) |
Aug
(72) |
Sep
(47) |
Oct
(9) |
Nov
(17) |
Dec
(11) |
2009 |
Jan
(139) |
Feb
(33) |
Mar
(16) |
Apr
(10) |
May
(11) |
Jun
(6) |
Jul
(86) |
Aug
(50) |
Sep
(13) |
Oct
(27) |
Nov
(59) |
Dec
(243) |
2010 |
Jan
(61) |
Feb
(31) |
Mar
(7) |
Apr
(22) |
May
(15) |
Jun
(12) |
Jul
(13) |
Aug
(33) |
Sep
(5) |
Oct
(33) |
Nov
(27) |
Dec
(19) |
2011 |
Jan
(16) |
Feb
(41) |
Mar
(7) |
Apr
(13) |
May
|
Jun
|
Jul
(10) |
Aug
(67) |
Sep
(7) |
Oct
(23) |
Nov
(5) |
Dec
(5) |
2012 |
Jan
(40) |
Feb
(53) |
Mar
(6) |
Apr
(35) |
May
(50) |
Jun
(19) |
Jul
(43) |
Aug
(110) |
Sep
(71) |
Oct
(24) |
Nov
(13) |
Dec
(18) |
2013 |
Jan
(13) |
Feb
(9) |
Mar
(29) |
Apr
(6) |
May
(18) |
Jun
(4) |
Jul
(24) |
Aug
(25) |
Sep
(30) |
Oct
(30) |
Nov
(8) |
Dec
(6) |
2014 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
(28) |
May
(6) |
Jun
(12) |
Jul
(8) |
Aug
(14) |
Sep
(128) |
Oct
(31) |
Nov
(27) |
Dec
(19) |
2015 |
Jan
(5) |
Feb
(3) |
Mar
(11) |
Apr
(4) |
May
(10) |
Jun
|
Jul
(1) |
Aug
(11) |
Sep
(20) |
Oct
(19) |
Nov
|
Dec
(6) |
2016 |
Jan
(1) |
Feb
(1) |
Mar
(11) |
Apr
(4) |
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
(6) |
Oct
(22) |
Nov
(6) |
Dec
(8) |
2017 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(6) |
Jul
(28) |
Aug
(87) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
From: Adrien P. <adr...@gm...> - 2017-08-12 09:44:02
|
Le Sat, 12 Aug 2017 10:45:14 +0200, Benoît Minisini via Gambas-devel <gam...@li...> a écrit: > Do I have to maintain the process of generating *.tar.gz source files > and uploading them to SourceForge? > > Or can I just rely on the "download" button of GitLab, and its download > URL? > You definitely can. :-) That's actually how most hosted projects handle their downloads : they just hand over the GitLab or GitHub URL related to a specific tag. -- Adrien Prokopowicz |
From: Adrien P. <adr...@gm...> - 2017-08-12 09:36:24
|
Le Sat, 12 Aug 2017 10:09:01 +0200, Benoît Minisini <ga...@us...> a écrit: > Le 12/08/2017 à 10:04, Benoît Minisini a écrit : >> Now I have to understand how to deal with your merge request... >> > > OK, there is a fix for WITH I must check. But there is something about > auto-completion that seems unrelated... Shouldn't you make two different > merge requests? > Yes sorry, I put the exclamation-mark completion work in another branch (I haven't made the Merge Request, because the first one needs to be merged first). There is still some completion changes, but these go along with the change in the compiler for nested WITHs. :-) Since you started working on the master branch, I disabled the automatic updates from SVN : because SVN has no idea about what's going on on Git, changes have to be manually merged instead of just fast-forwarded (I already merged #8175 into master). Also a small tip : in your account settings, you can also add your sourceforge email address to your account, this way the commits you made on SVN will be linked to your account instead of being from "another Benoît". :-) -- Adrien Prokopowicz |
From: Benoît M. <ga...@us...> - 2017-08-12 08:49:27
|
Le 16/10/2015 à 19:20, ML a écrit : > > Benoît, > > Well, I was speaking about SQL-92 and the like... > > ODBC has a way to fetch a block of rows. You can set how many. Then, it > will retrieve (up to) that many rows from the rowset. > You can, IIRC, also specify the starting offset. All this, of course, as > long as the Driver or RDBM provides scrollable cursors. > Mind you, I never tried a row-block fetch, and it will be a demanding > 'challenge' to overcome. My guess is that it will take some time. > > Please tell me how can gb.db.odbc know whether someone used the > DB.Limit() property, so I can make the next fetch a row-block fetch, and > how to recognize a "go back to retrieving 1 row at a time" mode change. > Related to that, one of the things that still escape me is which calls > in gb.db map to which (block of) calls in gb.db.odbc. That, and which > high level Gambas calls map to which gb.db (block of) calls. > > Regards, > Hi, I just noticed I didn't deal with your mail... Do you have a GitLab account so that I can add you to the GitLab Gambas group? Do you have a real name that I can use? :-) Regards, -- Benoît Minisini |
From: Benoît M. <ga...@us...> - 2017-08-12 08:45:20
|
Do I have to maintain the process of generating *.tar.gz source files and uploading them to SourceForge? Or can I just rely on the "download" button of GitLab, and its download URL? -- Benoît Minisini |
From: Benoît M. <ga...@us...> - 2017-08-12 08:09:08
|
Le 12/08/2017 à 10:04, Benoît Minisini a écrit : > > Now I have to understand how to deal with your merge request... > OK, there is a fix for WITH I must check. But there is something about auto-completion that seems unrelated... Shouldn't you make two different merge requests? -- Benoît Minisini |
From: Benoît M. <ga...@us...> - 2017-08-12 08:04:46
|
Le 12/08/2017 à 09:49, Adrien Prokopowicz a écrit : >> Very strange: 3.10.0 tag is present in the "tags" section of the >> repository, but not when you pop down the list "switch >> branch/tag"... > > It's there, but the list isn't sorted in natural order, so it's right > after the 3.1.0 version. Ha! > > I didn't push the branches for the stable versions, since the tags > have the same purpose : you can switch to any tag, and create a > branch from there if you want to make changes to an older version. > > (Actually, you can switch to any commit you want and create a branch > from there : commits are kind of like ref-counted, and a tag is just > a named reference to a commit). > > However, if I missed something and there is something needed in these > branches, I can push them back. > > For tagging new releases, as we've discussed in previous messages, > it's all done from the "stable" branch : right now it contains the > 3.10.0 version, you can either commit directly to it or cherry-pick > commits from the master branch (i.e. just take specific commits > instead of the whole branch, if you want only the bugfixes to tag a > patch release, say 3.10.1). So the 'stable' branch is the last stable version. But, as far as I understand, I have no branch for the other stable versions. It is not really problematic, as usually we do fixes only in the current stable version. If someday we have to make a fix in 3.9, for example, we can just create a stable branch for 3.9 from its latest tag, and work on it. Do I get it correctly? > > You can also merge the master branch into stable, which will apply > all the commits the stable branch didn't have, in order to tag a new > release, say 3.11. OK, I see. > > Once you're done and the stable branch contains what you want to > release, you just have to create an annotated tag[0]. (Annotated tags > have checksums and can be signed, unlike simple tags which are just > pointers). And then it's done. :-) > > [0] https://git-scm.com/book/en/v2/Git-Basics-Tagging > OK. Now I have to understand how to deal with your merge request... -- Benoît Minisini |
From: Adrien P. <adr...@gm...> - 2017-08-12 07:49:28
|
Le Sat, 12 Aug 2017 09:20:11 +0200, Benoît Minisini <ga...@us...> a écrit: > Le 12/08/2017 à 09:17, Benoît Minisini a écrit : >> Le 12/08/2017 à 09:12, Benoît Minisini via Gambas-devel a écrit : >>> Le 12/08/2017 à 09:08, Benoît Minisini a écrit : >>>> Le 12/08/2017 à 09:07, Benoît Minisini via Gambas-devel a écrit : >>>>>> >>>>>> The proper way to do this would be to keep the repository on the >>>>>> group (I invited you as an owner, so you should have full access to >>>>>> the group too), and then change your username (you'll find it under >>>>>> your icon > Settings > Account), >>>>> >>>>> OK, done. >>>>> >>>>>> so the group can be renamed "gambas", and so the repository will be >>>>>> named gambas/gambas. >>>>> >>>>> OK. done. >>>>> Nice, thank you ! >>>> >>>> Now, how to update the git repository to the latest svn? >>>> >>> >>> Aow. It is already up to date? Yes. I have a script running hourly on the playground's server to keep it updated. :-) >>> >> Now there is something I don't understand: >> - How can I make the 3.10.0 tag? From which branch? >> - Where are the branches of all stable versions? (3.10, 3.9, 3.8...) >> > Very strange: 3.10.0 tag is present in the "tags" section of the > repository, but not when you pop down the list "switch branch/tag"... It's there, but the list isn't sorted in natural order, so it's right after the 3.1.0 version. I didn't push the branches for the stable versions, since the tags have the same purpose : you can switch to any tag, and create a branch from there if you want to make changes to an older version. (Actually, you can switch to any commit you want and create a branch from there : commits are kind of like ref-counted, and a tag is just a named reference to a commit). However, if I missed something and there is something needed in these branches, I can push them back. For tagging new releases, as we've discussed in previous messages, it's all done from the "stable" branch : right now it contains the 3.10.0 version, you can either commit directly to it or cherry-pick commits from the master branch (i.e. just take specific commits instead of the whole branch, if you want only the bugfixes to tag a patch release, say 3.10.1). You can also merge the master branch into stable, which will apply all the commits the stable branch didn't have, in order to tag a new release, say 3.11. Once you're done and the stable branch contains what you want to release, you just have to create an annotated tag[0]. (Annotated tags have checksums and can be signed, unlike simple tags which are just pointers). And then it's done. :-) [0] https://git-scm.com/book/en/v2/Git-Basics-Tagging -- Adrien Prokopowicz |
From: Benoît M. <ga...@us...> - 2017-08-12 07:20:18
|
Le 12/08/2017 à 09:17, Benoît Minisini a écrit : > Le 12/08/2017 à 09:12, Benoît Minisini via Gambas-devel a écrit : >> Le 12/08/2017 à 09:08, Benoît Minisini a écrit : >>> Le 12/08/2017 à 09:07, Benoît Minisini via Gambas-devel a écrit : >>>>> >>>>> The proper way to do this would be to keep the repository on the >>>>> group (I invited you as an owner, so you should have full access to >>>>> the group too), and then change your username (you'll find it under >>>>> your icon > Settings > Account), >>>> >>>> OK, done. >>>> >>>>> so the group can be renamed "gambas", and so the repository will be >>>>> named gambas/gambas. >>>> >>>> OK. done. >>>> >>> >>> Now, how to update the git repository to the latest svn? >>> >> >> Aow. It is already up to date? >> > > Now there is something I don't understand: > > - How can I make the 3.10.0 tag? From which branch? > > - Where are the branches of all stable versions? (3.10, 3.9, 3.8...) > Very strange: 3.10.0 tag is present in the "tags" section of the repository, but not when you pop down the list "switch branch/tag"... -- Benoît Minisini |
From: Benoît M. <ga...@us...> - 2017-08-12 07:18:05
|
Le 12/08/2017 à 09:12, Benoît Minisini via Gambas-devel a écrit : > Le 12/08/2017 à 09:08, Benoît Minisini a écrit : >> Le 12/08/2017 à 09:07, Benoît Minisini via Gambas-devel a écrit : >>>> >>>> The proper way to do this would be to keep the repository on the >>>> group (I invited you as an owner, so you should have full access to >>>> the group too), and then change your username (you'll find it under >>>> your icon > Settings > Account), >>> >>> OK, done. >>> >>>> so the group can be renamed "gambas", and so the repository will be >>>> named gambas/gambas. >>> >>> OK. done. >>> >> >> Now, how to update the git repository to the latest svn? >> > > Aow. It is already up to date? > Now there is something I don't understand: - How can I make the 3.10.0 tag? From which branch? - Where are the branches of all stable versions? (3.10, 3.9, 3.8...) -- Benoît Minisini |
From: Benoît M. <ga...@us...> - 2017-08-12 07:12:35
|
Le 12/08/2017 à 09:08, Benoît Minisini a écrit : > Le 12/08/2017 à 09:07, Benoît Minisini via Gambas-devel a écrit : >>> >>> The proper way to do this would be to keep the repository on the >>> group (I invited you as an owner, so you should have full access to >>> the group too), and then change your username (you'll find it under >>> your icon > Settings > Account), >> >> OK, done. >> >>> so the group can be renamed "gambas", and so the repository will be >>> named gambas/gambas. >> >> OK. done. >> > > Now, how to update the git repository to the latest svn? > Aow. It is already up to date? -- Benoît Minisini |
From: Benoît M. <ga...@us...> - 2017-08-12 07:08:56
|
Le 12/08/2017 à 09:07, Benoît Minisini via Gambas-devel a écrit : >> >> The proper way to do this would be to keep the repository on the >> group (I invited you as an owner, so you should have full access to >> the group too), and then change your username (you'll find it under >> your icon > Settings > Account), > > OK, done. > >> so the group can be renamed "gambas", and so the repository will be >> named gambas/gambas. > > OK. done. > Now, how to update the git repository to the latest svn? -- Benoît Minisini |
From: Benoît M. <ga...@us...> - 2017-08-12 07:07:40
|
Le 12/08/2017 à 00:31, Adrien Prokopowicz a écrit : > Le Fri, 11 Aug 2017 23:54:46 +0200, Benoît Minisini > <ga...@us...> a écrit: >> >> Is it possible to transfer the repository to gambas/gambas ? What >> should I do for that? >> > > The proper way to do this would be to keep the repository on the > group (I invited you as an owner, so you should have full access to > the group too), and then change your username (you'll find it under > your icon > Settings > Account), OK, done. > so the group can be renamed "gambas", and so the repository will be > named gambas/gambas. OK. done. > > This way, we can put all gambas-related projects and repositories > under a single group (website, wiki, bugtracker, playground, etc.), > as well as the regularly contributing developers. > > However, if you wish to have the repository on your personal account > instead, I can initiate a repository transfer. You will then receive > a notification to complete it. > -- Benoît Minisini |
From: PICCORO M. L. <mck...@gm...> - 2017-08-12 01:21:40
|
> > Is it possible to transfer the repository to gambas/gambas ? What should > I do for that? > > -- > Beno?t Minisini Benoit, the proper way its like Adrian said: Puting the personal user as "gambas" makes it look like a dictatorship, everyone uses their identification appropriately, and "gambas" is a working group of a complete environment .. under this is the repository "gambas" and other future projects, is the right way.. also for the integration, the gitlab has a issue redirection in settings->integration->services * custom issue tracker : to made the gambas bugtraker the main when user click on "issues" * external wiki : to made a redirection to gambaswiki when somebody click on "wiki" * email on push : as do in old svn, sends mails on each push/pull/commits |
From: Adrien P. <adr...@gm...> - 2017-08-11 22:31:52
|
Le Fri, 11 Aug 2017 23:54:46 +0200, Benoît Minisini <ga...@us...> a écrit: > > Is it possible to transfer the repository to gambas/gambas ? What should > I do for that? > The proper way to do this would be to keep the repository on the group (I invited you as an owner, so you should have full access to the group too), and then change your username (you'll find it under your icon > Settings > Account), so the group can be renamed "gambas", and so the repository will be named gambas/gambas. This way, we can put all gambas-related projects and repositories under a single group (website, wiki, bugtracker, playground, etc.), as well as the regularly contributing developers. However, if you wish to have the repository on your personal account instead, I can initiate a repository transfer. You will then receive a notification to complete it. -- Adrien Prokopowicz |
From: Tony M. <tmo...@aj...> - 2017-08-11 21:55:21
|
Adrien, Great work! I'd like to become a contributor/developer. I'm retired so I have time to spare. My programming experience goes back almost 40 years, to a PDP-9. My C is very rusty, but my basic and Gambas is current. On 2017-08-11 05:24 PM, Adrien Prokopowicz wrote: > Le Sat, 22 Jul 2017 20:35:17 +0200, Adrien Prokopowicz > <adr...@gm...> 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, > > So I just took some time to clean up the repository, and I implemented > the > workflow we discussed in previous messages, with one little exception > : the > master branch is the development branch, and I created a "stable" > branch, which > currently contains the newly-released 3.10.0 version. > This way, the master branch works exactly like the old "trunk", which > makes the > migration easier (both form a svn-git and a developer standpoint). > > I also removed all the old version branches[0] and turned them into > actual tags > instead[1]. > > I also transferred the repo from my personal account to a new group : > https://gitlab.com/gambas-basic/gambas > > I invited Benoît as an owner, and Laurent and Fabien as developers. > If other regular contributors / component maintainers want to join, > just ask me here. :-) > > I would like the group to be simply called "gambas", but for that > Benoît needs > to change his username on GitLab first (right now it conflicts :-) ). > > Now that the repo is organized and usable, the only thing left to do > to fully > switch to Git(Lab) is to write the contributing guides and update the > wiki, > so that everybody can configure their clients and start working again. > > As a side note, it is amusing that even though the repo wasn't fully > migrated, > there is already enough work done in it to make examples for the git > workflow : > > - Last week, I made some small changes to how the WITH keyword works > (see bug > #1131 on the tracker[2]), but since these changes affect the > compiler and the > generated Gambas bytecode, I wanted to have Benoît review it, so I made > a new temporary branch (from master), and created a Merge Request[3] ! > - I also created another experimental branch[4] to try and build > Gambas with > CMake instead. This is an old project of mine that was never > completed, but > I decided to push it on the repo for experience sharing, because : > - Laurent Carlier wants to try and use Meson for building Gambas, > but since he had no access to the repository at all, he forked it to a > personal repository[5]. > This way, when he will be done he can create a Merge Request to > merge it > back into the main repository, which is a great way for other people to > contribute to Gambas. :-) > > You can also see all the branch shenanigans on the fancy graph here : > https://gitlab.com/gambas-basic/gambas/network/master > > [0] https://gitlab.com/gambas-basic/gambas/branches > [1] https://gitlab.com/gambas-basic/gambas/tags > [2] http://gambaswiki.org/bugtracker/edit?object=BUG.1131&from=L21haW4- > [3] https://gitlab.com/gambas-basic/gambas/merge_requests/1 > [4] https://gitlab.com/gambas-basic/gambas/tree/cmake > [5] https://gitlab.com/lordheavy/gambas/commits/meson-test |
From: Benoît M. <ga...@us...> - 2017-08-11 21:54:53
|
Le 11/08/2017 à 23:24, Adrien Prokopowicz a écrit : > > So I just took some time to clean up the repository, and I implemented the > workflow we discussed in previous messages, with one little exception : the > master branch is the development branch, and I created a "stable" > branch, which > currently contains the newly-released 3.10.0 version. > This way, the master branch works exactly like the old "trunk", which > makes the > migration easier (both form a svn-git and a developer standpoint). > > I also removed all the old version branches[0] and turned them into > actual tags > instead[1]. > > I also transferred the repo from my personal account to a new group : > https://gitlab.com/gambas-basic/gambas > > I invited Benoît as an owner, and Laurent and Fabien as developers. > If other regular contributors / component maintainers want to join, > just ask me here. :-) > > I would like the group to be simply called "gambas", but for that Benoît > needs > to change his username on GitLab first (right now it conflicts :-) ). > > Now that the repo is organized and usable, the only thing left to do to > fully > switch to Git(Lab) is to write the contributing guides and update the wiki, > so that everybody can configure their clients and start working again. > > As a side note, it is amusing that even though the repo wasn't fully > migrated, > there is already enough work done in it to make examples for the git > workflow : > > - Last week, I made some small changes to how the WITH keyword works > (see bug > #1131 on the tracker[2]), but since these changes affect the compiler > and the > generated Gambas bytecode, I wanted to have Benoît review it, so I made > a new temporary branch (from master), and created a Merge Request[3] ! > - I also created another experimental branch[4] to try and build Gambas > with > CMake instead. This is an old project of mine that was never > completed, but > I decided to push it on the repo for experience sharing, because : > - Laurent Carlier wants to try and use Meson for building Gambas, > but since he had no access to the repository at all, he forked it to a > personal repository[5]. > This way, when he will be done he can create a Merge Request to merge it > back into the main repository, which is a great way for other people to > contribute to Gambas. :-) > > You can also see all the branch shenanigans on the fancy graph here : > https://gitlab.com/gambas-basic/gambas/network/master > > [0] https://gitlab.com/gambas-basic/gambas/branches > [1] https://gitlab.com/gambas-basic/gambas/tags > [2] http://gambaswiki.org/bugtracker/edit?object=BUG.1131&from=L21haW4- > [3] https://gitlab.com/gambas-basic/gambas/merge_requests/1 > [4] https://gitlab.com/gambas-basic/gambas/tree/cmake > [5] https://gitlab.com/lordheavy/gambas/commits/meson-test Is it possible to transfer the repository to gambas/gambas ? What should I do for that? -- Benoît Minisini |
From: Adrien P. <adr...@gm...> - 2017-08-11 21:25:05
|
Le Sat, 22 Jul 2017 20:35:17 +0200, Adrien Prokopowicz <adr...@gm...> 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, So I just took some time to clean up the repository, and I implemented the workflow we discussed in previous messages, with one little exception : the master branch is the development branch, and I created a "stable" branch, which currently contains the newly-released 3.10.0 version. This way, the master branch works exactly like the old "trunk", which makes the migration easier (both form a svn-git and a developer standpoint). I also removed all the old version branches[0] and turned them into actual tags instead[1]. I also transferred the repo from my personal account to a new group : https://gitlab.com/gambas-basic/gambas I invited Benoît as an owner, and Laurent and Fabien as developers. If other regular contributors / component maintainers want to join, just ask me here. :-) I would like the group to be simply called "gambas", but for that Benoît needs to change his username on GitLab first (right now it conflicts :-) ). Now that the repo is organized and usable, the only thing left to do to fully switch to Git(Lab) is to write the contributing guides and update the wiki, so that everybody can configure their clients and start working again. As a side note, it is amusing that even though the repo wasn't fully migrated, there is already enough work done in it to make examples for the git workflow : - Last week, I made some small changes to how the WITH keyword works (see bug #1131 on the tracker[2]), but since these changes affect the compiler and the generated Gambas bytecode, I wanted to have Benoît review it, so I made a new temporary branch (from master), and created a Merge Request[3] ! - I also created another experimental branch[4] to try and build Gambas with CMake instead. This is an old project of mine that was never completed, but I decided to push it on the repo for experience sharing, because : - Laurent Carlier wants to try and use Meson for building Gambas, but since he had no access to the repository at all, he forked it to a personal repository[5]. This way, when he will be done he can create a Merge Request to merge it back into the main repository, which is a great way for other people to contribute to Gambas. :-) You can also see all the branch shenanigans on the fancy graph here : https://gitlab.com/gambas-basic/gambas/network/master [0] https://gitlab.com/gambas-basic/gambas/branches [1] https://gitlab.com/gambas-basic/gambas/tags [2] http://gambaswiki.org/bugtracker/edit?object=BUG.1131&from=L21haW4- [3] https://gitlab.com/gambas-basic/gambas/merge_requests/1 [4] https://gitlab.com/gambas-basic/gambas/tree/cmake [5] https://gitlab.com/lordheavy/gambas/commits/meson-test -- Adrien Prokopowicz |
From: Adrien P. <adr...@gm...> - 2017-07-28 20:17:11
|
Le Fri, 28 Jul 2017 22:11:10 +0200, Christof Thalhofer <ch...@de...> 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 |
From: Christof T. <ch...@de...> - 2017-07-28 20:11:19
|
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 |
From: Adrien P. <adr...@gm...> - 2017-07-28 20:04:43
|
Le Fri, 28 Jul 2017 21:57:56 +0200, Benoît Minisini <ga...@us...> a écrit: > Le 28/07/2017 à 21:51, Adrien Prokopowicz a écrit : >> Hi folks, I have a little question about Gambas Arrays in native >> components. >> In order to get/put data, according to the docs[0] the only way I have >> is to call >> Array.Get() to retrieve a pointer to the given index. >> But since calling this for every index could be pretty slow, I was >> wondering if I could >> consider the pointer returned by Array.Get(0) to be the start of a >> continuous memory >> block of the size of the array, so I could directly access it (and use >> memcpy and such) ? >> Having read the source code and tested a bit I think this is safe, but >> since the array >> type is opaque and there is no other exposed method than Get(), I would >> like to be >> sure there is no hidden shenanigan going on. :-) >> Regards, >> [0] http://gambaswiki.org/wiki/dev/api/cat/array >> > > Yes you can, provided that : > > - You correctly cast the void pointer returned by Array.Get(0). > > - You understand that this pointer is valid until you add ore remove > elements. > > Regards, > Okay, thanks for the confirmation ! :) I'll probably add this to the wiki when i have some time, since this can be quite useful. Regards, -- Adrien Prokopowicz |
From: Benoît M. <ga...@us...> - 2017-07-28 19:58:04
|
Le 28/07/2017 à 21:51, Adrien Prokopowicz a écrit : > Hi folks, I have a little question about Gambas Arrays in native > components. > > In order to get/put data, according to the docs[0] the only way I have > is to call > Array.Get() to retrieve a pointer to the given index. > > But since calling this for every index could be pretty slow, I was > wondering if I could > consider the pointer returned by Array.Get(0) to be the start of a > continuous memory > block of the size of the array, so I could directly access it (and use > memcpy and such) ? > > Having read the source code and tested a bit I think this is safe, but > since the array > type is opaque and there is no other exposed method than Get(), I would > like to be > sure there is no hidden shenanigan going on. :-) > > Regards, > > [0] http://gambaswiki.org/wiki/dev/api/cat/array > Yes you can, provided that : - You correctly cast the void pointer returned by Array.Get(0). - You understand that this pointer is valid until you add ore remove elements. Regards, -- Benoît Minisini |
From: Adrien P. <adr...@gm...> - 2017-07-28 19:51:14
|
Hi folks, I have a little question about Gambas Arrays in native components. In order to get/put data, according to the docs[0] the only way I have is to call Array.Get() to retrieve a pointer to the given index. But since calling this for every index could be pretty slow, I was wondering if I could consider the pointer returned by Array.Get(0) to be the start of a continuous memory block of the size of the array, so I could directly access it (and use memcpy and such) ? Having read the source code and tested a bit I think this is safe, but since the array type is opaque and there is no other exposed method than Get(), I would like to be sure there is no hidden shenanigan going on. :-) Regards, [0] http://gambaswiki.org/wiki/dev/api/cat/array -- Adrien Prokopowicz |
From: Adrien P. <adr...@gm...> - 2017-07-28 19:24:44
|
Le Fri, 28 Jul 2017 18:03:37 +0200, PICCORO McKAY Lenz <mck...@gm...> a écrit: > but please mantain a firm-name to the branches! like gb.xx.yy.dev > i mean added last word ".dev" at the end to enphasis the devel of that > componente, that due git can mantain history of >the artifact.. > the history of that branchs are important due must help to other > developer to see in the history how the problem are >resolved in the > time line.. You mean adding ".dev" to help seeing this is an in-development branch ? Because Git does not care what your branches are named (besides master), so I don't see how it helps Git "maintain history"… Also, you have to see the experimental branches as temporary ones. When you are done with your feature, you get it merged into the development branch (without squashing the commits of course !), and then you delete the branch. From experience, I can say that you do not want old branches laying around or it will become an huge mess in no time. Moreover, in the rare case you want to consult the history, looking at the file/directory's history is easier than looking for the history of a branch. So there is no point in keeping them, at least for our case. > again in that case, the devel branch must named gambas3-devel and the > experimental gambas3-experimental > > so gambas<X>-<type> where X are the mayor release, and tyope the > working development branch type There wouldn't be an "experimental" branch, but one for each non-ready feature. > this anwers the question made by Cris, lest see: >but WAITH STILL NEED ENTION MERGE AND PULL PATCHES FROM USERS its > important! No caps needed there, it's not the end of the world. With this workflow, user-submitted merge requests (or pull requests in GitHub terminology) are managed just like with the "internal" experimental branches. The user just has to fork the repository to its own, branch from the development version, work on their own branch, then submit a merge request to merge their branch back in the development version. If the code is approved, then it gets merged and done. :) > well in github/gitlab, there's a feature that limits the pull request > and merge request to the already commiters! > users can request also joint to propose a pull reques.. > > if you guys dont do that, maybe the pull repo will be like the > codeigniter or like the owncloud, a large pull request of >issues.. I'm not sure I understand, you're afraid that there may be too many pull requests ? First, I think this if a false problem. Not only contributions are very welcome, but both GitLab and GitHub provide tools to handle big amounts of pull requests. An example of project with lots of contributions is Rust[0] : they've got like 20 pull requests in the last 7 days (not counting the closed ones), and because they properly tagged everything, I know what every pull request needs, and from who, even if I have no idea what they actually are about. Also, making users ask permission to open merge requests make no sense at all. A merge request (as its name implies) is already a request from an user to merge code in the main repository (with code review from the maintainers). So they would have to make a request to make a request to merge code ? :-) [0] https://github.com/rust-lang/rust/pulls -- Adrien Prokopowicz |
From: PICCORO M. L. <mck...@gm...> - 2017-07-28 16:03:44
|
here i anwer the question made by Crist! and make some corrections to the post of Adrien: Date: Fri, 28 Jul 2017 16:35:44 +0200 > From: "Adrien Prokopowicz" <adr...@gm...> > To: "mailing list for gambas developers" > <gam...@li...> > Subject: Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab) > about that Adrien said: > 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) > its the most similar workflow, according to my git experience and svn experience.. but please mantain a firm-name to the branches! like gb.xx.yy.dev i mean added last word ".dev" at the end to enphasis the devel of that componente, that due git can mantain history of the artifact.. the history of that branchs are important due must help to other developer to see in the history how the problem are resolved in the time line.. > > 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. > again in that case, the devel branch must named gambas3-devel and the experimental gambas3-experimental so gambas<X>-<type> where X are the mayor release, and tyope the working development branch type > 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. > exactly! > > 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. > its almost like but works but WAITH STILL NEED ENTION MERGE AND PULL PATCHES FROM USERS its important! this anwers the question made by Cris, lest see: > From: Christof Thalhofer <ch...@de...> > To: mailing list for gambas developers > <gam...@li...> > Subject: Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab) > Message-ID: <a1c...@de...> > Content-Type: text/plain; charset="utf-8" > > 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. > but WAITH STILL NEED ENTION MERGE AND PULL PATCHES FROM USERS its important! that feature are not present in the svn, due the svn are limited to developers of the gambas repository.. how will be that? well in github/gitlab, there's a feature that limits the pull request and merge request to the already commiters! users can request also joint to propose a pull reques.. if you guys dont do that, maybe the pull repo will be like the codeigniter or like the owncloud, a large pull request of issues.. |
From: Adrien P. <adr...@gm...> - 2017-07-28 15:38:35
|
Le Fri, 28 Jul 2017 17:06:41 +0200, Christof Thalhofer <ch...@de...> 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 |