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
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 branches to avoid conflicts/breaking other people’s code.
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. 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. 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.
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. 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 (**). The checkout command for any version then becomes “git checkout branch@{timestamp}”. Both the built VMs via a -version flag, and sources via a header file, will be marked with these timestamps.
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.
We will integrate the Github commit notifications with a Codespeed instance that will test commits for performance regressions.
Action Items
Write the commit script
Set a date for the move (sooner rather than later)
Move the repository
Enable automatic builds for all the platforms
Write GNU makefiles for unix/linux
Hi Folks,
This is just great!
I assume builds will include:
- V3, Cog, 32bitBinaries
- Spur32, Cog, 32bitBinaries
- Spur64, Cog, 64bitBinaries
Would it also be possible to include:
- V3, Stack, 32bitBinaries
- Spur32, Stack, 32bitBinaries
- Spur64, Stack, 64bitBinaries
?
I think that having the non-Cog builds always green could benefit those platforms where code generation is not possible, and might ease porting to new platforms. Especially for Spur64.
Thanks you all!
Juan Vuletich