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?