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