Greetings, I have a question for the community in general, and Marc in particular. As some of you may know the Pediatric Anesthesia Research team at UBC uses Gambit as part of their LambdaNative framework (http://www.lambdanative.org/) to develop medical software. Some of our applications are mission and safety critical as they control drug delivery to patients (doi: 10.1145/2635648.2635651), or provide decision support during triage of pregnant women by community health workers (doi: 10.1109/JBHI.2014.2301156). Hence, we are trying to identify which version of Gambit to use, with the main deciding factor being reliability and stability.
While the main LambdaNative branch uses 4.7.9 - we are considering updating to 4.8.5 once we figure out how to integrated the revised tracing into our exception handler/logger, we use much older versions for our production-quality applications: Specifically, we use 4.7.2 for our mobile Android apps, as there were issues with both the ##thread-heartbeat! and other hard-to-reproduce crashes in very large Android apps with later Gambit versions. For our closed-loop system on Linux we reverted back even further at 4.7.0. Here, our attempt to update to 4.7.9 resulted in weeks of debugging after the application segfaulted during clinical pilot testing, having passed weeks of both manual and automated system tests in the lab. Unfortunately, we were never to identify the exact crash location, but all we could show was that the crash did not originate from our (user-level) code but the Gambit infrastructure code.
I appreciate that the project's current goals are more along the line of making a more universal output language processor, which is a laudable endeavor e.g. for improved in-browser support. However, I would appreciate some guidance in helping us chose a "stable" version without potentially wasting man-months in testing (and failing) to identify such a version ourselves.
Many Thanks, Matthias
Afficher les réponses par date
Hello Matthias. I can understand your need for determining the most reliable version of Gambit. Usually, “releases” (the commits tagged with a version number in git) are produced when the system passes all the unit tests and is able to bootstrap itself (which exercices many parts of the system). Of course bugs can go unnoticed and there have been a handful of releases with important bugs (these are normally corrected by issuing a new release within a few days of the buggy release).
Personally, I don’t keep track of which release is the most reliable. I’m always working on the bleeding edge. I would say the best way to tell which release is the most reliable is with the git log and the github issue tracker.
I urge you to submit github issue reports whenever you encounter problems with the system so that they can be addressed promptly and other users can be aware of these issues, for example the issues you are having on Android.
Also, when you encounter a situation where Gambit is acting unexpectedly or crashing, please try to create a unit test that will reproduce the problem. Then this can be added to the current set of unit tests to ensure that this issue will not happen in future releases. If the issue occurs on a certain platform (Android?) then some continuous integration service supporting that platform should be added to Gambit (currently every commit is tested by Travis CI and Appveyor, and this covers linux, macOS and Windows with various C compilers and configuration options).
I’d like to hear what other users have to say about Gambit's reliability, and how it can be improved and tracked.
Marc
On Jun 21, 2016, at 11:51 AM, Gorges, Matthias MGorges@cw.bc.ca wrote:
Greetings, I have a question for the community in general, and Marc in particular. As some of you may know the Pediatric Anesthesia Research team at UBC uses Gambit as part of their LambdaNative framework (http://www.lambdanative.org/) to develop medical software. Some of our applications are mission and safety critical as they control drug delivery to patients (doi: 10.1145/2635648.2635651), or provide decision support during triage of pregnant women by community health workers (doi: 10.1109/JBHI.2014.2301156). Hence, we are trying to identify which version of Gambit to use, with the main deciding factor being reliability and stability.
While the main LambdaNative branch uses 4.7.9 - we are considering updating to 4.8.5 once we figure out how to integrated the revised tracing into our exception handler/logger, we use much older versions for our production-quality applications: Specifically, we use 4.7.2 for our mobile Android apps, as there were issues with both the ##thread-heartbeat! and other hard-to-reproduce crashes in very large Android apps with later Gambit versions. For our closed-loop system on Linux we reverted back even further at 4.7.0. Here, our attempt to update to 4.7.9 resulted in weeks of debugging after the application segfaulted during clinical pilot testing, having passed weeks of both manual and automated system tests in the lab. Unfortunately, we were never to identify the exact crash location, but all we could show was that the crash did not originate from our (user-level) code but the Gambit infrastructure code.
I appreciate that the project's current goals are more along the line of making a more universal output language processor, which is a laudable endeavor e.g. for improved in-browser support. However, I would appreciate some guidance in helping us chose a "stable" version without potentially wasting man-months in testing (and failing) to identify such a version ourselves.
Many Thanks, Matthias _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Dear Marc, Thanks for your kind response.
I urge you to submit github issue reports whenever you encounter problems with the system so that they can be addressed promptly and other users can be aware of these issues, for example the issues you are having on Android.
Would you actually be interested in us filing issues against older versions of Gambit (as we don't run the current one)? I am aware that the core Gambit development team is very small, so I could understand that you might not want to maintain those versions.
Personally, I don't keep track of which release is the most reliable. I'm always working on the bleeding edge. I would say the best way to tell which release is the most reliable is with the git log and the github issue tracker.
You'll appreciate that bleeding edge would not be something I would personally be comfortable with giving that "not crashing" is really important for medical use. Do you know how many users use a given version of Gambit - this might inform our decision of what people deem to be stable (optimal) as it works well for them? One reason to choose 4.7.2 is that this was before you did a major internal rewrite towards the goal of output language independence. The changelog to 4.7.3 is long, and as a non-compiler writer I can't really appreciate which of these things are potentially scary to us. The main limitation of 4.7.2 is that it doesn't support arm64, so we would need to patch it to make our "stable" version. - In the meantime we'll also look at 4.8.5.
If the issue occurs on a certain platform (Android?) then some continuous integration service supporting that platform should be added to Gambit (currently every commit is tested by Travis CI and Appveyor, and this covers linux, macOS and Windows with various C compilers and configuration options).
Your suggestion of increasing the breath of unit tests and considering continuous integration (CI) services is great! However, we mainly create mobile apps (iOS and android), whereby the system state and data depend on previous user interactions. A module to replay mouse clicks and keyboard entries was devised, but in the end we didn't find this particularly useful. Here I would welcome suggestions from others of how they test their mobile apps using CI service?
Many Thanks, Matthias
2016-06-28 0:38 GMT+08:00 Gorges, Matthias MGorges@cw.bc.ca:
Dear Marc, Thanks for your kind response.
I urge you to submit github issue reports whenever you encounter problems with the system so that they can be addressed promptly and other users can be aware of these issues, for example the issues you are having on Android.
Would you actually be interested in us filing issues against older versions of Gambit (as we don't run the current one)? I am aware that the core Gambit development team is very small, so I could understand that you might not want to maintain those versions.
There would certainly be a point with some rare "long term support" versions.
(A risk with contributing on the bleeding edge only is that one bug may have been fixed but another introduced.)
On 06/27/2016 12:38 PM, Gorges, Matthias wrote:
Would you actually be interested in us filing issues against older versions of Gambit (as we don't run the current one)? I am aware that the core Gambit development team is very small, so I could understand that you might not want to maintain those versions.
Whether any of this happens depends entirely on Marc.
I might suggest, though, that a specific, relatively recent version of Gambit be nominated for "long term support" and that problems from all platforms be reported against that *one* version.
If I understand correctly, you're currently using different versions on different platforms because of bugs and workarounds on those different platforms for different versions of Gambit. (That may not be so clear, but I think you know what I mean.) Fixing bugs on several Gambit versions at once might seem too broad a support surface.
Brad
Hi Brad,
Whether any of this happens depends entirely on Marc.
Yes, it is a scary thought that we develop mission critical software using a library with a very low bus factor (https://en.wikipedia.org/wiki/Bus_factor). If Gambit wouldn't work as beautifully as it does, we could consider switching LambdaNative's underlying Scheme compiler (ChezScheme?).
I might suggest, though, that a specific, relatively recent version of Gambit be nominated for "long term support" and that problems from all platforms be reported against that *one* version.
That sounds like a good plan - maybe 4.7.2 with a few patches to make arm64 work?
If I understand correctly, you're currently using different versions on different platforms because of bugs and workarounds on those different platforms for different versions of Gambit.
Correct - we mainly use 4.7.0 and 4.7.2 internally, which are both from before the big refactoring towards multiple output language support. After 4.7.3 there are some freezing (and segfault) issues in Android when using usb-serial devices. The 4.7.0 reason is that the last time we tried to upgrade to 4.7.9 our team wasted about a month trying to pin down a fatal crash, which was eliminated by rolling back to the older libgambc version. Two Android crash examples below:
Build fingerprint: 'google/razor/flo:4.4.4/KTU84P/1227136:user/release-keys' pid: 6106, tid: 6119, name: Thread-128 >>> org.ecemgroup.clip <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 3ff00028 Stack frame #00 pc 0070c678 /data/app-lib/org.ecemgroup.clip-1/libpayloadshared.so: Routine heartbeat_interrupt_handler at /Users/mg/.lambdanative/tmp_install/gambit-4.8.5/lib/os_time.c:971 Stack frame #01 pc 000004fc [vectors]
Build fingerprint: 'google/razor/flo:4.4.4/KTU84P/1227136:user/release-keys' pid: 25772, tid: 25855, name: Thread-238 >>> org.ecemgroup.clip <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 Stack frame #00 pc 00000000 <unknown> Stack frame #01 pc 00713004 /data/app-lib/org.ecemgroup.clip-2/libpayloadshared.so (___raise_interrupt_vmstate+40): Routine ___raise_interrupt_vmstate at /Users/mg/.lambdanative/tmp_install/gambit-4.8.5/lib/setup.c:98
Thanks Matthias
I guess the best approach would be to create a “v4.7.0-lts” branch in the Gambit git repo. Then any fixes to issues that are discovered could be added to that branch specifically. However, nothing that adds functionality would be added to an “lts” branch as this might break existing functionality.
As development of the master branch progresses, a newer release of Gambit that is stable could be identified and a new “lts” branch could be created. This would happen every 2 years or so, similarly to Ubuntu.
Due to the overhead of doing this, I would appreciate if someone stepped forward to oversee the management of this process. Matthias, would you be willing to do this?
Marc
On Jul 4, 2016, at 9:11 PM, Gorges, Matthias MGorges@cw.bc.ca wrote:
Hi Brad,
Whether any of this happens depends entirely on Marc.
Yes, it is a scary thought that we develop mission critical software using a library with a very low bus factor (https://en.wikipedia.org/wiki/Bus_factor). If Gambit wouldn't work as beautifully as it does, we could consider switching LambdaNative's underlying Scheme compiler (ChezScheme?).
I might suggest, though, that a specific, relatively recent version of Gambit be nominated for "long term support" and that problems from all platforms be reported against that *one* version.
That sounds like a good plan - maybe 4.7.2 with a few patches to make arm64 work?
If I understand correctly, you're currently using different versions on different platforms because of bugs and workarounds on those different platforms for different versions of Gambit.
Correct - we mainly use 4.7.0 and 4.7.2 internally, which are both from before the big refactoring towards multiple output language support. After 4.7.3 there are some freezing (and segfault) issues in Android when using usb-serial devices. The 4.7.0 reason is that the last time we tried to upgrade to 4.7.9 our team wasted about a month trying to pin down a fatal crash, which was eliminated by rolling back to the older libgambc version. Two Android crash examples below:
Build fingerprint: 'google/razor/flo:4.4.4/KTU84P/1227136:user/release-keys' pid: 6106, tid: 6119, name: Thread-128 >>> org.ecemgroup.clip <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 3ff00028 Stack frame #00 pc 0070c678 /data/app-lib/org.ecemgroup.clip-1/libpayloadshared.so: Routine heartbeat_interrupt_handler at /Users/mg/.lambdanative/tmp_install/gambit-4.8.5/lib/os_time.c:971 Stack frame #01 pc 000004fc [vectors]
Build fingerprint: 'google/razor/flo:4.4.4/KTU84P/1227136:user/release-keys' pid: 25772, tid: 25855, name: Thread-238 >>> org.ecemgroup.clip <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 Stack frame #00 pc 00000000 <unknown> Stack frame #01 pc 00713004 /data/app-lib/org.ecemgroup.clip-2/libpayloadshared.so (___raise_interrupt_vmstate+40): Routine ___raise_interrupt_vmstate at /Users/mg/.lambdanative/tmp_install/gambit-4.8.5/lib/setup.c:98
Thanks Matthias _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
2016-07-05 20:56 GMT+08:00 Marc Feeley feeley@iro.umontreal.ca:
I guess the best approach would be to create a “v4.7.0-lts” branch in the Gambit git repo.
Neat!
Then any fixes to issues that are discovered could be added to that branch
specifically. However, nothing that adds functionality would be added to an “lts” branch as this might break existing functionality.
Right, only what is essentially a bug fix would fit.
(The "___RESULT()" macro you added recently would be as close to a new feature as it would go, I guess, as it was actually a form of fix to a very material problem, if I understood you right.)
As development of the master branch progresses, a newer release of Gambit
that is stable could be identified and a new “lts” branch could be created. This would happen every 2 years or so, similarly to Ubuntu.
Wonderful!
Similarly, lots of production use of Apache was of version 1.3 *Very* long after the 2-series came into existence. https://en.wikipedia.org/wiki/Apache_HTTP_Server#Development
Apache seem to do it every ~4 - 4.5 years BTW, and rathermore according to major structural changes in interfaces and the like if I got it right.
Maybe for Gambit around v4.7.0 is a sweet spot as it's right pre-universal backend and -SMP.
Some time after SMP will come into existence will, I guess, also be such a point.
Hi Marc,
I guess the best approach would be to create a "v4.7.0-lts" branch in the Gambit git repo. Then any fixes to issues that are discovered could be added to that branch specifically.
That would be great - Our team can propose a few patches we would need to have in there. Certainly the amd64 support needed to build for iOS from 4.7.3. Additionally see Adam's remark below.
2016-07-05 10:01 GMT+08:00 Adam <adam.mlmb@gmail.commailto:adam.mlmb@gmail.com>: I agree that 4.7.0 is good. I use it too and have for very long. I also experienced some issue when attempting to upgrade. (And some Gambit internals changed after this also so a few Black Hole internals would need upgrade which take time.) I'm essentially not aware of any bug in 4.7.0 (except for |will-execute!| which by design leaks memory on all versions). (Ah right, and a compile-time error on Linux, #ifdef USE_select needs to be changed to #ifdef USE_POSIX in lib/os_time.h , that is all.)
As development of the master branch progresses, a newer release of Gambit that is stable could be identified and a new "lts" branch could be created. This would happen every 2 years or so, similarly to Ubuntu.
Maybe a bit longer than that as we would already be past the 2-year mark for 4.7.0. (or 4.7.2 for that matter).
Due to the overhead of doing this, I would appreciate if someone stepped forward to oversee the management of this process. Matthias, would you be willing to do this?
I have never written a compiler before so I need to have a discussion with Chris to identify what our team can do to help.
Thanks Matthias
Re going with 4.7.0 or .2 because we know it works extremely well, maybe Brad's suggestion of taking a more recent Gambit version could be a productive idea also.
At least that would serve to help pushing Gambit forward. (That is, we would find and resolve any bugs in the more recent version.)
Perhaps doing two LTE:s, one for 4.7.0 and one for the current repo head, would make the most sense. We would know 4.7.0 works best currently that's all.
2016-07-05 7:59 GMT+08:00 Bradley Lucier lucier@math.purdue.edu:
On 06/27/2016 12:38 PM, Gorges, Matthias wrote:
Would you actually be interested in us filing issues against older
versions of Gambit (as we don't run the current one)? I am aware that the core Gambit development team is very small, so I could understand that you might not want to maintain those versions.
Whether any of this happens depends entirely on Marc.
I might suggest, though, that a specific, relatively recent version of Gambit be nominated for "long term support" and that problems from all platforms be reported against that *one* version.
If I understand correctly, you're currently using different versions on different platforms because of bugs and workarounds on those different platforms for different versions of Gambit. (That may not be so clear, but I think you know what I mean.) Fixing bugs on several Gambit versions at once might seem too broad a support surface.
Brad _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
LTS is a great idea but its also a fair amount of work so my humble opinion would be to go for a much more recent release and work out any stability issues that you may have from there which as Adam suggests could also benefit the users who track releases as well, doesn't make a lot of sense to start an LTS release now using a years old release of Gambit.
I'm happy to provide some debugging assistance as I'm working with OSX / iOS currently but I could also be convinced to set up an Android testing environment, it would just be a matter of finding the time.
Not at all trying to push my personal requirements here but I'd be happy to contribute assistance to a more modern LTS. Personally I'd hate to see Marc get tied up managing LTS branches rather than pushing Gambit in new and exciting directions.
James
On Wed, Jul 6, 2016 at 11:14 AM, Adam adam.mlmb@gmail.com wrote:
Re going with 4.7.0 or .2 because we know it works extremely well, maybe Brad's suggestion of taking a more recent Gambit version could be a productive idea also.
At least that would serve to help pushing Gambit forward. (That is, we would find and resolve any bugs in the more recent version.)
Perhaps doing two LTE:s, one for 4.7.0 and one for the current repo head, would make the most sense. We would know 4.7.0 works best currently that's all.
2016-07-05 7:59 GMT+08:00 Bradley Lucier lucier@math.purdue.edu:
On 06/27/2016 12:38 PM, Gorges, Matthias wrote:
Would you actually be interested in us filing issues against older
versions of Gambit (as we don't run the current one)? I am aware that the core Gambit development team is very small, so I could understand that you might not want to maintain those versions.
Whether any of this happens depends entirely on Marc.
I might suggest, though, that a specific, relatively recent version of Gambit be nominated for "long term support" and that problems from all platforms be reported against that *one* version.
If I understand correctly, you're currently using different versions on different platforms because of bugs and workarounds on those different platforms for different versions of Gambit. (That may not be so clear, but I think you know what I mean.) Fixing bugs on several Gambit versions at once might seem too broad a support surface.
Brad _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
2016-07-06 12:01 GMT+08:00 James Baker cycle.code.media@gmail.com:
LTS is a great idea but its also a fair amount of work so my humble opinion would be to go for a much more recent release and work out any stability issues that you may have from there which as Adam suggests could also benefit the users who track releases as well, doesn't make a lot of sense to start an LTS release now using a years old release of Gambit.
Maybe two make sense, a very recent one *and* 4.7.X?
4.7.X is not *so* old, and it works so well already, so from a short-term risk point of view it makes a lot of sense to work with. But sure I totally see your point.
Personally I'd hate to see Marc get tied up managing LTS branches rather than pushing Gambit in new and exciting directions.
Totally.
I think for now I'd vote for two, like this. An LTE can always be discontinued or less maintained in the future. An awareness should build up fairly quickly about their pros/cons.
Also of course there are certain bugs that will not go away, e.g. the non-collectin of manually trigged testators - because it's relatively deep in the GC. Those bugs should simply be listed for the individual LTE.
Maybe the "___result()" macro should be brought to the LTE as it solves something.
Maybe the new unit tests and compile scripts for platforms should be moved in to the LTE for safety and platform completeness, which is pretty close to the "bug fixing" definition.
This altogether does not look like a whole lot of work to me -
I guess Marc may need to review and accept the pull requests to the LTE:s, that would be about as much as he needs to do.
Thoughts?
And a next step would be, exactly which 4.7.X commit should be chosen, and which recent commit?
What I would like is for someone (or a group) to step up to act as the maintainer of these stable branches of Gambit.
The maintainer’s initial rôle would be to identify the version that seems the most appropriate (v4.7.?) and to create a git branch of that version. The most recent set of unit-tests should then be added to that branch.
Then, there is the more tedious process of identifying which commits since that version are bug fixes that should be added to the stable branch. There are roughly 1000 commits since v4.7.0 . Going through each of these commits would have to be done to see if it fixes an issue that affects the stable branch. The github issues page could be used to quickly identify the most obvious issues (for example https://github.com/gambit/gambit/issues/181).
The maintainer could also manage a branch created from a recent version of Gambit. That would have the advantage that fewer commits would have to be analyzed and more features would be available. However, it would require a higher level of involvement from users to validate the correctness of this branch in their use cases (I’m thinking of the UBC group among others).
I think those most interested in the creation of a stable branch should be the decision makers here, as they are the main beneficiaries of this effort, and they also need to be actively involved in the maintenance (as the maintainer or users of the stable branch).
Marc
On Jul 13, 2016, at 2:06 AM, Adam adam.mlmb@gmail.com wrote:
2016-07-06 12:01 GMT+08:00 James Baker cycle.code.media@gmail.com: LTS is a great idea but its also a fair amount of work so my humble opinion would be to go for a much more recent release and work out any stability issues that you may have from there which as Adam suggests could also benefit the users who track releases as well, doesn't make a lot of sense to start an LTS release now using a years old release of Gambit.
Maybe two make sense, a very recent one *and* 4.7.X?
4.7.X is not *so* old, and it works so well already, so from a short-term risk point of view it makes a lot of sense to work with. But sure I totally see your point.
Personally I'd hate to see Marc get tied up managing LTS branches rather than pushing Gambit in new and exciting directions.
Totally.
I think for now I'd vote for two, like this. An LTE can always be discontinued or less maintained in the future. An awareness should build up fairly quickly about their pros/cons.
Also of course there are certain bugs that will not go away, e.g. the non-collectin of manually trigged testators - because it's relatively deep in the GC. Those bugs should simply be listed for the individual LTE.
Maybe the "___result()" macro should be brought to the LTE as it solves something.
Maybe the new unit tests and compile scripts for platforms should be moved in to the LTE for safety and platform completeness, which is pretty close to the "bug fixing" definition.
This altogether does not look like a whole lot of work to me -
I guess Marc may need to review and accept the pull requests to the LTE:s, that would be about as much as he needs to do.
Thoughts?
And a next step would be, exactly which 4.7.X commit should be chosen, and which recent commit?
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Dear Marc,
The maintainer's initial rôle would be to identify the version that seems the most appropriate (v4.7.?) and to create a git branch of that version. The most recent set of unit-tests should then be added to that branch.
This sounds like a great plan and I would be happy to help maintaining an older (e.g. 4.7.0-based) branch of Gambit. I would assume that you'd eventually host this branch in the official Gambit repository? We can provide a list of potential patches to it. Also by making this branch the default version in LambdaNative it will likely get a lot of use. However, I am not a compiler developer so there might be some limitations of what I can do with respect of troubleshooting problems with it.
For a start we (part-cw) could fork a 4.7.0 version and apply some patches against it to see what we'd like in a LTS version? It might be good to start an issue on Github as a central place to track the efforts needed to make this happen. Would you be happy with this?
The maintainer could also manage a branch created from a recent version of Gambit.
I don't think we can do this as we still use 4.7.9 internally and are very uncomfortable to go there due to the 1000+ changes you mentioned, most of which are unrelated to the C-backend we use. Hence, someone else would need to step up for this 4.8.5-based LTS version. I did, however, file an issue against it to point out one potential difference I noticed.
Many Thanks, Matthias
I'd be happy to volunteer to help out for the more recent LTS branch, I just wont be able to find the time to help with a 4.7.x. I completely understand the desire to have the older branch its just too far away from what I want to use in the future and my work is absorbing a lot of my time currently.
In terms of management would it work to just have a couple of branches in the primary git repo?
I'm guessing Marc wouldn't want a whole load of random users having the ability to make a mess in HEAD but I believe github has the ability to restrict user access to particular branches so that might be one option to investigate?
James
On Thu, Jul 14, 2016 at 9:21 AM, Gorges, Matthias MGorges@cw.bc.ca wrote:
Dear Marc,
The maintainer's initial rôle would be to identify the version that seems the most appropriate (v4.7.?) and to create a git branch of that version. The most recent set of unit-tests should then be added to that branch.
This sounds like a great plan and I would be happy to help maintaining an older (e.g. 4.7.0-based) branch of Gambit. I would assume that you'd eventually host this branch in the official Gambit repository? We can provide a list of potential patches to it. Also by making this branch the default version in LambdaNative it will likely get a lot of use. However, I am not a compiler developer so there might be some limitations of what I can do with respect of troubleshooting problems with it.
For a start we (part-cw) could fork a 4.7.0 version and apply some patches against it to see what we'd like in a LTS version? It might be good to start an issue on Github as a central place to track the efforts needed to make this happen. Would you be happy with this?
The maintainer could also manage a branch created from a recent version of Gambit.
I don't think we can do this as we still use 4.7.9 internally and are very uncomfortable to go there due to the 1000+ changes you mentioned, most of which are unrelated to the C-backend we use. Hence, someone else would need to step up for this 4.8.5-based LTS version. I did, however, file an issue against it to point out one potential difference I noticed.
Many Thanks, Matthias _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Hi James,
I'd be happy to volunteer to help out for the more recent LTS branch, I just wont be able to find the time to help with a 4.7.x.
Great!
I'm guessing Marc wouldn't want a whole load of random users having the ability to make a mess in HEAD but I believe github has the ability to restrict user access to particular branches so that might be one option to investigate?
It does, see https://help.github.com/articles/about-branch-restrictions/. However, I would not be opposed to work with pull requests from a forked repository that Marc would merge into the official LTS branch.
In terms of management would it work to just have a couple of branches in the primary git repo?
One master branch and two LTS branches should do? We'll need to figure out how to build LTS releases from them though.
Cheers Matthias
Hi Matthias,
Whatever works for the majority I'm fine with whether its pull requests, branches with independent managers or a different work flow entirely, ultimately I suppose that decision rests with Marc.
In terms of release management perhaps it would be possible to adapt the current process that Marc has? I think it would be great to integrate LTS branches into the CI process as well.
Cheers,
James
On Thu, Jul 14, 2016 at 10:23 AM, Gorges, Matthias MGorges@cw.bc.ca wrote:
Hi James,
I'd be happy to volunteer to help out for the more recent LTS branch, I just wont be able to find the time to help with a 4.7.x.
Great!
I'm guessing Marc wouldn't want a whole load of random users having the ability to make a mess in HEAD but I believe github has the ability to restrict user access to particular branches so that might be one option to investigate?
It does, see https://help.github.com/articles/about-branch-restrictions/. However, I would not be opposed to work with pull requests from a forked repository that Marc would merge into the official LTS branch.
In terms of management would it work to just have a couple of branches in the primary git repo?
One master branch and two LTS branches should do? We'll need to figure out how to build LTS releases from them though.
Cheers Matthias
2016-07-14 7:21 GMT+08:00 Gorges, Matthias MGorges@cw.bc.ca: [..]
The maintainer could also manage a branch created from a recent version of Gambit.
I don't think we can do this as we still use 4.7.9 internally and are very uncomfortable to go there due to the 1000+ changes you mentioned, most of which are unrelated to the C-backend we use. Hence, someone else would need to step up for this 4.8.5-based LTS version. I did, however, file an issue against it to point out one potential difference I noticed.
Over time someone will do it (weed out bugs in /a/ newer version/-s).
However, maybe it's not the right time to fork off an LTS from a recent version now - maybe we should wait until SMP is out and matured, so like, we can do the next LTS fork next summer (July 2017).
Of course ordinary bug-hunting in HEAD is/should be going on as usual.
Isn't it correct to say that the additional central functionality in Gambit that matured since 4.7.0, is the multilanguage backend, whose perhaps biggest utility is the JS-output.
(Also the multiple-GVM-in-one-process functionality matured, could be backported perhaps.)
While supposedly people use this, maybe it's not of such importance that an LTS is needed for it.
But it is clear that at least one LTS is needed. So landing at one LTS and that one being 4.7.X is perhaps the optimum thing LTS-wise for the next 12 months, thoughts?
2016-07-13 23:04 GMT+08:00 Marc Feeley feeley@iro.umontreal.ca:
What I would like is for someone (or a group) to step up to act as the maintainer of these stable branches of Gambit.
The maintainer’s initial rôle would be to identify the version that seems the most appropriate (v4.7.?) and to create a git branch of that version. The most recent set of unit-tests should then be added to that branch.
Then, there is the more tedious process of identifying which commits since that version are bug fixes that should be added to the stable branch. There are roughly 1000 commits since v4.7.0 . Going through each of these commits would have to be done to see if it fixes an issue that affects the stable branch. The github issues page could be used to quickly identify the most obvious issues (for example https://github.com/gambit/gambit/issues/181).
The maintainer could also manage a branch created from a recent version of Gambit. That would have the advantage that fewer commits would have to be analyzed and more features would be available. However, it would require a higher level of involvement from users to validate the correctness of this branch in their use cases (I’m thinking of the UBC group among others).
I think those most interested in the creation of a stable branch should be the decision makers here, as they are the main beneficiaries of this effort, and they also need to be actively involved in the maintenance (as the maintainer or users of the stable branch).
Marc
To get things going, for practicality, we could bootstrap the LTS process in a slightly lazier way according to an action plan something like, just create an "official LTS branch" (of the decided-on 4.7.X version) in the Gambit repo, or anywhere else.
And then, merge in all the commits that we know already are needed.
We all have time for this already because we do it already, and doing this is faster than systemically going through *all* commits since Oct 2013 up to now.
We should go through all of them however but it's not going to happen overnight.
Then some thoughts on the LTS maintenance -
I'm thinking a particular "LTS maintenance protocol" should be devised for the LTS branch, something like that:
* After the initial formative phase the next 3-4 months, the introduction of a *rule* that a *pull request must be quarantained for 90 days* and be *OK-ed by at least three people, *ON* the emailing list*.
And perhaps that the pull request must be taken through some specified build, testing and code analysis tools.
* Some kind of documentation over the status of the distribution, e.g., that the README/.md/ file lists essential information about what's in and what's not in the box -
GitHub issues are valuable for tracking bugs, but they might have a too high turnover rate to be useful as documentation maybe.
Maybe a list of all the commits and changes that have been made in addition the original version.
An *errata* listing "known specifics, bug-like features and bugs" such as the non-collection (leakage) of (will-execute! (make-will (box #f) (lambda (t) (void)))) .
The point is that it should be extremely clear to everyone what is and what is not in the box.
* Also a writeup in the same document of what newer Gambit functionality is and is not back-ported into the LTS, so everyone can be clear about decisions.
Generally nothing is backported but there may be some corner-case, perhaps, such as the ___RESULT() macro which is a form of bug-fix, and perhaps bignum library speedups and similar tweaks that are of trivial complexity.
And this protocol should be documented in README/.md/ too.
All in the name of almost-total conservatism and safety.
Thoughts?
On 07/13/2016 11:00 PM, Adam wrote:
I'm thinking a particular "LTS maintenance protocol" should be devised for the LTS branch, something like that:
- After the initial formative phase the next 3-4 months, the
introduction of a _rule_ that a _pull request must be quarantained for 90 days_ and be _OK-ed by at least three people, *ON* the emailing list_.
And perhaps that the pull request must be taken through somespecified build, testing and code analysis tools.
I often get the feeling that there aren't three people on the mailing list qualified to give an opinion on a specific patch, whether they wanted to or not. (I'm certainly not qualified to comment on the majority of Marc's patches.)
Perhaps we should just give the UBC people whatever they want to start, and then work out protocols after we see what might be working.
Brad
I agree with Brad. Let’s not blow this out of proportion. I don’t foresee very deep work on new patches. It is mostly picking patches from those done since that version so there has already been a decent level of scrutiny. Also we could have “lts” and “lts-candidate” branches so the patches can go to lts-candidate first and if the interested parties (to be determined) give their ok then the patch is applied to lts too.
Marc
On Jul 15, 2016, at 11:39 PM, Bradley Lucier lucier@math.purdue.edu wrote:
On 07/13/2016 11:00 PM, Adam wrote:
I'm thinking a particular "LTS maintenance protocol" should be devised for the LTS branch, something like that:
- After the initial formative phase the next 3-4 months, the
introduction of a _rule_ that a _pull request must be quarantained for 90 days_ and be _OK-ed by at least three people, *ON* the emailing list_.
And perhaps that the pull request must be taken through some specified build, testing and code analysis tools.
I often get the feeling that there aren't three people on the mailing list qualified to give an opinion on a specific patch, whether they wanted to or not. (I'm certainly not qualified to comment on the majority of Marc's patches.)
Perhaps we should just give the UBC people whatever they want to start, and then work out protocols after we see what might be working.
Brad
2016-07-16 19:52 GMT+08:00 Marc Feeley feeley@iro.umontreal.ca:
I agree with Brad. Let’s not blow this out of proportion.
Right, yes.
I don’t foresee very deep work on new patches. It is mostly picking patches from those done since that version so there has already been a decent level of scrutiny.
Good point.
Also we could have “lts” and “lts-candidate” branches so the patches can go to lts-candidate first and if the interested parties (to be determined) give their ok then the patch is applied to lts too.
I guess noone will ever be in disagreement about commits that are kept in there, so there's not any need even for that.
Anyone who uses HEAD needs to review any commits new to him obviously.
So the next step is.. action?
[Sorry for the repeated posting but I’m having problems with my email…]
The first order of business is choosing which version(s) of Gambit to branch from. It could be more than one version if various groups or individuals have different requirements. I foresee that the maintenance of these branches will be driven by these groups, so there is no reason to place a limit of 1. However, for the sake of focus, we should probably not maintain more than 2 or 3 “stable” branches in the long run and I think we should start with one branch to see how it goes.
So lets first determine which branch to start from… v4.7.0 or v4.7.2 or other?
Also how should we name the branches… I propose “v4.7.0-stable”.
Marc
On Jul 16, 2016, at 1:01 PM, Adam adam.mlmb@gmail.com wrote:
2016-07-16 19:52 GMT+08:00 Marc Feeley feeley@iro.umontreal.ca: I agree with Brad. Let’s not blow this out of proportion.
Right, yes.
I don’t foresee very deep work on new patches. It is mostly picking patches from those done since that version so there has already been a decent level of scrutiny.
Good point.
Also we could have “lts” and “lts-candidate” branches so the patches can go to lts-candidate first and if the interested parties (to be determined) give their ok then the patch is applied to lts too.
I guess noone will ever be in disagreement about commits that are kept in there, so there's not any need even for that.
Anyone who uses HEAD needs to review any commits new to him obviously.
So the next step is.. action?
Hi Adam,
4.7.X is not *so* old, and it works so well already, so from a short-term risk point of view it makes a lot of sense to work with. But sure I totally see your point.
I agree that we should have at least one proven stable version.
Maybe the new unit tests and compile scripts for platforms should be moved in to the LTE for safety and platform completeness, which is pretty close to the "bug fixing" definition.
We started a list of potential commits that would be needed (and those nice to have) if the LTE version would be 4.7.0. However, there are likely others I may have missed so Marc and the community might need to add some more.
a6f919a Correctly identify arm64 architecture so that little-endian ffd839c Fix typo for MSVC build on Windows a2d0e19 Fix an issue with x86 backend unit tests 4c868ca Add a unit testing framework (and anything in gambit/tests/*) 83e2078 Fix live-sleeping problem on OS X due to heartbeat
And potentially these: 0dce1c3 Syntax case improvement 095fba6 Improve the performance of bignum division 2fbf7cd Add support for high-resolution timing on Windows
Many Thanks, Matthias
On 07/13/2016 12:39 PM, Gorges, Matthias wrote:
We started a list of potential commits that would be needed (and those nice to have) if the LTE version would be 4.7.0. However, there are likely others I may have missed so Marc and the community might need to add some more.
a6f919a Correctly identify arm64 architecture so that little-endian ffd839c Fix typo for MSVC build on Windows a2d0e19 Fix an issue with x86 backend unit tests 4c868ca Add a unit testing framework (and anything in gambit/tests/*) 83e2078 Fix live-sleeping problem on OS X due to heartbeat
And potentially these: 0dce1c3 Syntax case improvement 095fba6 Improve the performance of bignum division 2fbf7cd Add support for high-resolution timing on Windows
A side question: Is there an easy way to find these patches on github given the patch numbers, as you gave?
Brad
Dear Brad,
A side question: Is there an easy way to find these patches on github given the patch numbers, as you gave?
Sure, you can go to https://github.com/gambit/gambit/commit/%5BHASH], using the commit hashes I listed. For example: * a6f919a Correctly identify arm64 architecture so that little-endian https://github.com/gambit/gambit/commit/a6f919a
Cheers Matthias
-
Adam -
Bradley Lucier -
Gorges, Matthias -
James Baker -
James Baker -
Marc Feeley