- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Ben Coman

On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > El 28-06-2017, a las 02:57, Ben Coman <btc(a)openinworld.com> escribiÃ³: > > > > On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com > > wrote: > >> >> >> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: >> >>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>> <pavel.krivanek(a)gmail.com> wrote: >>> > >>> > >>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich < >>> serge.stinckwich(a)gmail.com>: >>> >> >>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>> >> <pavel.krivanek(a)gmail.com> wrote: >>> >> > Hi, >>> >> > >>> >> > this mail describes how to start to send pull requests to Pharo 7 >>> Github >>> >> > repository from Pharo 7. >>> >> >>> >> Thank you for the great explanation Pavel. >>> >> >>> >> > Preparations >>> >> > ===================== >>> >> > >>> >> > - you need to have a Github account and set SSH keys. See >>> >> > https://help.github.com/articles/connecting-to-github-with-ssh/ >>> >> > - create own pharo-project/pharo repository fork. Go to >>> >> > https://github.com/pharo-project/pharo, click on "Fork" button and >>> >> > follow >>> >> > the instructions >>> >> >>> >> [ ... ] >>> >> >>> >> > Issue processing >>> >> > ===================== >>> >> > >>> >> > - create new case on FogBugz to get the issue number >>> >> > - open Iceberg and from the context menu on the 'pharo' repository >>> do: >>> >> > Pharo >>> >> > - Create new branch from FogBugz issue, enter the issue ID and it >>> will >>> >> > fill >>> >> > the full branch name for you >>> >> > - create your changes (you can do it before the creation of the >>> branch >>> >> > too) >>> >> > - commit and push your changes in Iceberg, this way you will commit >>> your >>> >> > branch to your fork repository. Remember that the Iceberg commit >>> window >>> >> > has >>> >> > two buttons, one for local commit, the second for commit with >>> immediate >>> >> > push. They can be very long because they contain the full branch >>> (issue) >>> >> > name >>> >> > - in Iceberg in the 'pharo' repository context menu do: Pharo - >>> Create >>> >> > pull >>> >> > request, fill your >>> >> > - fill your Github credentials >>> >> > - leave the PR title, comment is not required, check the pull >>> request >>> >> > head >>> >> > and base. The base MUST be pharo-project/pharo development. Create >>> the >>> >> > pull >>> >> > requests >>> >> > - go to https://github.com/pharo-project/pharo/pulls, check your >>> pull >>> >> > requests and put URL of it into the issue record on FogBugz (as a >>> >> > comment). >>> >> > Resolve the issue as Fix review needed >>> >> >>> >> It means, there is no PR without a corresponding FogBugz issue ? >>> > >>> > >>> > Yes, at least for code changes we would like to keep this relation. If >>> it is >>> > a really trivial change in readme or something like that, we can >>> accept no >>> > related issue record. >>> > Please prefer to comment the issues instead of PRs directly to have all >>> > information at one place. >>> >>> Thank you Pavel for the explanation. >>> >>> Maybe in the future, it will make sense to put everything in the PR >>> and use github issues. >>> You will use CI travis builds for all PR ? >>> >> >> For now we will use FogBugz because it has a lot of nice features and >> good API. Maybe we will switch it in future but now we should not change >> too many things at once :-) >> For several reasons we now prefer to use own infrastructure for checking >> of PRs (mainly because of MacOS issues on Travis). But again, it can be >> changed in future. >> >> > It would be interesting to see how this might fit in with our workflow... > https://blog.fogcreek.com/fogbugz-github-integration/ > > > > What is the benefit of the integration? I do not understand it from the > given link. > > When you submit a PR on github, Fogbugz is automatically updated with a link to the PR. Presumably this makes it easier for people reviewing cases in Fogbugz to identify the slice to test. This is a better link... https://blog.fogcreek.com/improved-github-integration-automatically-create-… cheers -ben

June 28, 2017

[FT improvements] [GSoC] [guidance needed] move some of the data source responsibilities to the cells

by Elhamer

Dear Pharo community, I've been working on improving the FT package recently and i would like to get your opinions about introducing a new cell data source layer. The idea is to move some of the data source responsibilities to the <cell data source, cell morph> in order to have a 'less dumber cell morphs' and a better design that reduces the complexity of extending the functionalities of a fast table. The changes are kind of expensive and might break Glamour and some other FT-based packages out there (unless the new implementation is integrated in the FT package as an alternative way -the old implementation will be deprecated and removed progressively-). There three main parts in the fast table package: - The data source - The table Morph - The cell Morph In the current design, all data managements are centralized around the data source. The Data source has the following responsibilities (schema below): - Creates the cell Morphs and populate them (cellColumn: column row: rowIndex). - Creates the header cells Morphs. - Manipulates the data that will be used to populate the table. - Updates the cell data (when the strong selection announcement is handled for example). <http://forum.world.st/file/n4952783/old_impl.png> * Limitation of this design:* - A high level of complexity in the data source. - The cell morph is a dumb object and itâs not being used to its full potential. - Extending the cell functionalities (usually done from the data source) can be challenging. A better design would be for the cell morph to interact directly with a new layer of data source âthe cell data sourceâ, and the cell's data source will propagate to the tableâs data source (the table refresh will triggered from the table's data source). Here are the responsibilities for each part (schema below): *The cell Morph responsibilities:* - Handle mouse/keyboard events and fire announcements. *The cell data source responsibilities:* - Handles cellâs announcements and manage cellâs data. - Propagates the changes to the data source. - Creates the cell morphs. *The tableâs data source responsibilities:* - Send refresh messages to the table morph when data changed. - Create the cell data sources object for each data element. *The table morph responsibilities:* - Render the morphs/widgets â¦ - Handle column/row selection. - â¦ <http://forum.world.st/file/n4952783/new_impl.png> *Requirement changes:* *The cell data source:* - A light version of the data source package to manage cell content. - â¦ *Announcements:* - Create new cells announcements that propagate the required properties to the cell's data source to handle data changes. - Propagate those announcements when the required event is fired on the cell morph. - â¦ *The data source* - Creates cells' data sources instead of cell Morphs. - â¦ *The cell Morph* - Fires the announcements, plus some tiny changes to bound the morph to its data source. - â¦ *The table Morph* - The FTTableMorph doesnât need much modification, just few changes here and there, The FTTableContainerMorph might be improved as well to take advantage from the fact that the cell morph knows its data (probably a better exposed-rows updates). - â¦ *Notes:* - These updates will definitely break Glamour, so some changes to the Glamour FT package is also required. - The best way to introduce these changes is by adding this new cell data source layer side by side with the current implementation, and mark the old implementation as deprecated (will be removed progressively in the next versions). Thank you :) Best regards, Elhamer. -- View this message in context: http://forum.world.st/FT-improvements-GSoC-guidance-needed-move-some-of-the… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 28, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Pierce Ng

On Tue, Jun 27, 2017 at 02:56:48PM +0200, Sven Van Caekenberghe wrote: > P3 is a modern, lean and mean PostgreSQL client for Pharo. > P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. This is great stuff! Pierce

June 28, 2017

Why is there a __MACOSX directory in the zeroconf linux download?

by Tim Mackinnon

Hi - I just noticed when trying out zeroconf on an EC2 instance that the resulting download for the 64 bit vm has a __MACOSX directory in it in the pharo-vm/lib/5.x directory? Isnât this built with a CI server - so why is that file in there? Or are these vmâs hand built? Tim

June 28, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Norbert Hartl

> Am 28.06.2017 um 12:43 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> On 28 Jun 2017, at 12:14, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> >>> Am 28.06.2017 um 10:42 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> >>>> On 28 Jun 2017, at 10:07, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> Great! I assume it is a smalltalk only client? >>> >>> Yes, it is written in pure Pharo, using a TCP network connection to PostgreSQL. >>> >>>> As we have protocol version 3.0 does it mean that protocol 4.0 will be announced shortly? :) >>> >>> Hmm, I guess you're joking, AFAIK there is no protocol 4.0 (this is the front-end/back-end or client-server protocol to talk to the DB). >>> >> Yes, I was joking, of course. I thought this was obvious. > > ;-) > >>>> Great work! Although I do not use SQL databases I need to check. >>> >>> Well, that might be a mistake. PostgreSQL is very good and does most things that NoSQL DB's do, like key-value storage, JSON, XML, documents, .. often just as fast. Being a bit more traditional, cautious at the DB level is considered good in many circles. >>> >> Ok, I understand. I'm aware of json store capabilities. But I'm not aware about queries using nested json attributes or combined indexes using nested json attributes. Is it possible? > > Yes it seems to be possible: https://www.postgresql.org/docs/9.6/static/datatype-json.html <https://www.postgresql.org/docs/9.6/static/datatype-json.html> > Ah ok, need to read that. >> You are the only I hear in the last time calling postgres fast. > > Here is one article that I read recently, but I have seen others as well: https://containership.engineering/dynamodb-to-postgres-why-and-how-aa891681… <https://containership.engineering/dynamodb-to-postgres-why-and-how-aa891681…> > >> And what do you mean by "being cautious"? > > In terms of Enterprise speak, easier to sell, more trustworthy, better known, â¦ > You mean like C and Java ;) ( <- author is joking! ) Norbert >> Norbert >> >> >>>> Norbert >>>> >>>> >>>>> Am 27.06.2017 um 14:56 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>>>> >>>>> P3 is a modern, lean and mean PostgreSQL client for Pharo. >>>>> >>>>> P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. >>>>> >>>>> With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. >>>>> >>>>> More info, usage examples and code at https://github.com/svenvc/P3 >>>>> >>>>> P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. >>>>> >>>>> This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. >>>>> >>>>> Sven >>>>> >>>>> PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban !

June 28, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Sven Van Caekenberghe

> On 28 Jun 2017, at 12:14, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 28.06.2017 um 10:42 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >>> On 28 Jun 2017, at 10:07, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> Great! I assume it is a smalltalk only client? >> >> Yes, it is written in pure Pharo, using a TCP network connection to PostgreSQL. >> >>> As we have protocol version 3.0 does it mean that protocol 4.0 will be announced shortly? :) >> >> Hmm, I guess you're joking, AFAIK there is no protocol 4.0 (this is the front-end/back-end or client-server protocol to talk to the DB). >> > Yes, I was joking, of course. I thought this was obvious. ;-) >>> Great work! Although I do not use SQL databases I need to check. >> >> Well, that might be a mistake. PostgreSQL is very good and does most things that NoSQL DB's do, like key-value storage, JSON, XML, documents, .. often just as fast. Being a bit more traditional, cautious at the DB level is considered good in many circles. >> > Ok, I understand. I'm aware of json store capabilities. But I'm not aware about queries using nested json attributes or combined indexes using nested json attributes. Is it possible? Yes it seems to be possible: https://www.postgresql.org/docs/9.6/static/datatype-json.html > You are the only I hear in the last time calling postgres fast. Here is one article that I read recently, but I have seen others as well: https://containership.engineering/dynamodb-to-postgres-why-and-how-aa891681… > And what do you mean by "being cautious"? In terms of Enterprise speak, easier to sell, more trustworthy, better known, ... > Norbert > > >>> Norbert >>> >>> >>>> Am 27.06.2017 um 14:56 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> >>>> P3 is a modern, lean and mean PostgreSQL client for Pharo. >>>> >>>> P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. >>>> >>>> With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. >>>> >>>> More info, usage examples and code at https://github.com/svenvc/P3 >>>> >>>> P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. >>>> >>>> This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. >>>> >>>> Sven >>>> >>>> PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban !

June 28, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Norbert Hartl

> Am 28.06.2017 um 10:42 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > >> On 28 Jun 2017, at 10:07, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Great! I assume it is a smalltalk only client? > > Yes, it is written in pure Pharo, using a TCP network connection to PostgreSQL. > >> As we have protocol version 3.0 does it mean that protocol 4.0 will be announced shortly? :) > > Hmm, I guess you're joking, AFAIK there is no protocol 4.0 (this is the front-end/back-end or client-server protocol to talk to the DB). > Yes, I was joking, of course. I thought this was obvious. >> Great work! Although I do not use SQL databases I need to check. > > Well, that might be a mistake. PostgreSQL is very good and does most things that NoSQL DB's do, like key-value storage, JSON, XML, documents, .. often just as fast. Being a bit more traditional, cautious at the DB level is considered good in many circles. > Ok, I understand. I'm aware of json store capabilities. But I'm not aware about queries using nested json attributes or combined indexes using nested json attributes. Is it possible? You are the only I hear in the last time calling postgres fast. And what do you mean by "being cautious"? Norbert >> Norbert >> >> >>> Am 27.06.2017 um 14:56 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> P3 is a modern, lean and mean PostgreSQL client for Pharo. >>> >>> P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. >>> >>> With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. >>> >>> More info, usage examples and code at https://github.com/svenvc/P3 >>> >>> P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. >>> >>> This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. >>> >>> Sven >>> >>> PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban ! >>

June 28, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Sven Van Caekenberghe

> On 28 Jun 2017, at 10:07, Norbert Hartl <norbert(a)hartl.name> wrote: > > Great! I assume it is a smalltalk only client? Yes, it is written in pure Pharo, using a TCP network connection to PostgreSQL. > As we have protocol version 3.0 does it mean that protocol 4.0 will be announced shortly? :) Hmm, I guess you're joking, AFAIK there is no protocol 4.0 (this is the front-end/back-end or client-server protocol to talk to the DB). > Great work! Although I do not use SQL databases I need to check. Well, that might be a mistake. PostgreSQL is very good and does most things that NoSQL DB's do, like key-value storage, JSON, XML, documents, .. often just as fast. Being a bit more traditional, cautious at the DB level is considered good in many circles. > Norbert > > >> Am 27.06.2017 um 14:56 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> P3 is a modern, lean and mean PostgreSQL client for Pharo. >> >> P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. >> >> With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. >> >> More info, usage examples and code at https://github.com/svenvc/P3 >> >> P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. >> >> This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. >> >> Sven >> >> PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban ! >

June 28, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Norbert Hartl

Great! I assume it is a smalltalk only client? As we have protocol version 3.0 does it mean that protocol 4.0 will be announced shortly? :) Great work! Although I do not use SQL databases I need to check. Norbert > Am 27.06.2017 um 14:56 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > P3 is a modern, lean and mean PostgreSQL client for Pharo. > > P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. > > With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. > > More info, usage examples and code at https://github.com/svenvc/P3 > > P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. > > This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. > > Sven > > PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban !

June 28, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Juraj Kubelka

> El 28-06-2017, a las 02:57, Ben Coman <btc(a)openinworld.com> escribiÃ³: > > > > On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: > > > 2017-06-27 16:17 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: > On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: > > > > > > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: > >> > >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek > >> <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: > >> > Hi, > >> > > >> > this mail describes how to start to send pull requests to Pharo 7 Github > >> > repository from Pharo 7. > >> > >> Thank you for the great explanation Pavel. > >> > >> > Preparations > >> > ===================== > >> > > >> > - you need to have a Github account and set SSH keys. See > >> > https://help.github.com/articles/connecting-to-github-with-ssh/ <https://help.github.com/articles/connecting-to-github-with-ssh/> > >> > - create own pharo-project/pharo repository fork. Go to > >> > https://github.com/pharo-project/pharo <https://github.com/pharo-project/pharo>, click on "Fork" button and > >> > follow > >> > the instructions > >> > >> [ ... ] > >> > >> > Issue processing > >> > ===================== > >> > > >> > - create new case on FogBugz to get the issue number > >> > - open Iceberg and from the context menu on the 'pharo' repository do: > >> > Pharo > >> > - Create new branch from FogBugz issue, enter the issue ID and it will > >> > fill > >> > the full branch name for you > >> > - create your changes (you can do it before the creation of the branch > >> > too) > >> > - commit and push your changes in Iceberg, this way you will commit your > >> > branch to your fork repository. Remember that the Iceberg commit window > >> > has > >> > two buttons, one for local commit, the second for commit with immediate > >> > push. They can be very long because they contain the full branch (issue) > >> > name > >> > - in Iceberg in the 'pharo' repository context menu do: Pharo - Create > >> > pull > >> > request, fill your > >> > - fill your Github credentials > >> > - leave the PR title, comment is not required, check the pull request > >> > head > >> > and base. The base MUST be pharo-project/pharo development. Create the > >> > pull > >> > requests > >> > - go to https://github.com/pharo-project/pharo/pulls <https://github.com/pharo-project/pharo/pulls>, check your pull > >> > requests and put URL of it into the issue record on FogBugz (as a > >> > comment). > >> > Resolve the issue as Fix review needed > >> > >> It means, there is no PR without a corresponding FogBugz issue ? > > > > > > Yes, at least for code changes we would like to keep this relation. If it is > > a really trivial change in readme or something like that, we can accept no > > related issue record. > > Please prefer to comment the issues instead of PRs directly to have all > > information at one place. > > Thank you Pavel for the explanation. > > Maybe in the future, it will make sense to put everything in the PR > and use github issues. > You will use CI travis builds for all PR ? > > For now we will use FogBugz because it has a lot of nice features and good API. Maybe we will switch it in future but now we should not change too many things at once :-) > For several reasons we now prefer to use own infrastructure for checking of PRs (mainly because of MacOS issues on Travis). But again, it can be changed in future. > > > It would be interesting to see how this might fit in with our workflow... > https://blog.fogcreek.com/fogbugz-github-integration/ <https://blog.fogcreek.com/fogbugz-github-integration/> What is the benefit of the integration? I do not understand it from the given link. Thanks! Juraj > > cheers -ben

June 28, 2017