[gambit-list] Gambit version for medical apps?

Adam adam.mlmb at gmail.com
Wed Jul 13 23:00:46 EDT 2016


2016-07-13 23:04 GMT+08:00 Marc Feeley <feeley at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20160714/bf082569/attachment.htm>


More information about the Gambit-list mailing list