[Vm-dev] Minutes of the Meeting to Discuss Moving Cog to Github

[Ben Coman]

Cool to hear of this concrete progress. Thanks everyone involved.

On Sat, May 21, 2016 at 1:28 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi All,
>
>     here are the minutes of, and action items arising from, the meeting on Wednesday 18th of May to discuss moving the Cog svn repository to Github.  Please read if you're interested and discuss on vm-dev.  The major decision for the community to participate in is when to make the change, which we hope will happen in the next few weeks.  Thanks to all who attended the meeting and to all who have helped in making this a reality.  This is exciting!
>
> VM Move to Github Meeting Notes
>
> The name of the organisation and repository was agreed to be, and has been created as
> Organisation name: OpenSmalltalk
> Repository name: vm
> URL: github.com/OpenSmalltalk/vm

Great choice. I see Tobias has already created it...
https://github.com/opensmalltalk
https://api.github.com/orgs/OpenSmalltalk


> Administration duties:
> Tim Felgentreff, David Lewis, Esteban Lorenzano, Eliot Miranda
>
> We decided to have everyone who currently has access to SVN also get write access to the new repository.
>
>
> There will be a master branch that is stable and from which releases are made using tags. Only administrators integrate into that branch. Ongoing development will be on a “dev” branch. This should also be kept stable for collaboration purposes, but breakage can happen occasionally. Contributors working on larger changes will do so on separate [feature] branches to avoid conflicts/breaking other people’s code.

This seems a bit like Gitflow workflow [1]?
[1] https://www.atlassian.com/git/tutorials/comparing-workflows/
with the releases handled differently by directly tagging the master
branch rather than first working in a release branch.

> Every commit will be tested by Travis (and Appveyor for Windows). Builds and tests will be run for Windows, Linux, and OS X, both on 32-bit, 64-bit, and ARM (as applicable). The master will only ever be merged with green commits.

Will Travis auto-merge green dev commits into master like this...
https://chrisdown.name/2015/09/27/auto-merging-successful-builds-from-travis-ci.html

Or will it be more manual, like the release branches described for Gitflow ?

> The dev branch should be green, and if something breaks, but the committer has no access or no time to fix it, we agreed that any administrator may roll back the breaking change using git revert.

Have you considered Travis doing pre-merge testing...
https://blog.travis-ci.com/2012-09-04-pull-requests-just-got-even-more-awesome/

Even if this isn't configured for regular contributors going direct to
the dev branch (to retain an svn feel), it might be useful for pull
requests from irregular contributors like myself, who likely issue
pull requests from their forked repository.

> This way, the breaking change is preserved in the history, but the current HEAD is green. We will also disable “force-pushing” to the repository to ensure that no commit history can be tampered with.

Would it be worthwhile for master to only merge fast-forward [2] [3]
so that merging from dev to master can't accidentally create an
additional merge?  I presume there should be no changes in master that
didn't already pass through dev? That is...
     git config branch.master.mergeoptions "--ff-only
"
[2] http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html
[3] https://walkingthestack.blogspot.com.au/2011/09/set-default-merge-options-for-git.html
(Disclaimer: I've only read about this point, not used it)

> In case of any disagreements about reverting other people’s code, we declared Eliot (*) to be the arbiter.
>
> Release tags on the master will trigger Travis to build release artifacts, including debian packages.

> To have incremental monotonic, human-readable version identifiers, we decided to use timestamps in the form YYYYMMDDHHmm in UTC.

Putting so many numbers together like this...
201605210154
is not quite human readable and error prone if manually typing a
branch or tag to checkout (even if you'd usually cut-n-paste).

Adding a couple of spacers might be useful...
2016.0521.0154
since period separators seem valid...
https://git-scm.com/docs/git-check-ref-format

> In order to ensure these timestamps are included in the sources, we will have a commit script in the repository that any contributor must use to update the dev and master branches (**). Both the built VMs via a -version flag, and sources via a header file, will be marked with these timestamps.

> (**) use whatever versioning you want on your own versions, but the versions in OpenSmalltalk/vm will use this convention exclusively

Rather than just let everyone go their own way outside the official
dev builds, could the build system be set up to provide a community
convention identifying unofficial builds.  Build could be clearly
identified as unofficial by appending the commit hash, would also
uniquely identifys them.
So -version would return something like...
    2016.0521.0154-63ae94dae

where the timestamp from the official build is retained unchanged, to
identify where we branched off from the official repository.  It might
even be useful to add feature and user name,
so -version for unofficial builds looked like this...
    2016.0521.0154-63ae94dae-FeatureBranch-GitUserName


> The checkout command for any version then becomes “git checkout branch@{timestamp}”.

Is the "branch@" necessary?  It seems redundant and may clutter up the
graphs and reports.  Why not just...
   git checkout 2016.0521.0154

cheers -ben

> It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3)).
>
> We discussed ethics, which derive from the “if you break it, you fix it” philosophy and distilled it into the “administrators may revert” policy above.  We don’t want to prevent breakages, nor make people afraid of breaking things.  We merely want to prevent other people being affected by breakages, especially those that may be operating under production or time constraints.