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

Eliot Miranda eliot.miranda at gmail.com
Fri May 20 13:28:49 EDT 2016

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

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

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
   - Make WebHooks for Commit Notifications available to anyone who wants
   - Write CMake code to generate per-platform headers (***)

best, Eliot

(*) under protest
(**) use whatever versioning you want on your own versions, but the
versions in OpenSmalltalk/vm will use this convention exclusively
(***) which will /not/ be called "config.h", but e.g. "ostvmConfig.h", so
as to avoid conflicts with other packages using autoconf and CMake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20160520/0af8706d/attachment.html>

More information about the Pharo-dev mailing list