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

[Tim Felgentreff]

Hi Ben,

On 21 May 2016 at 19:44, Ben Coman <btc at openinworld.com> wrote:
>
> 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

No, we will have a merge through pull requests, because Travis cannot
check everything for us, and it would be difficult to sync e.g.
Windows build status (which will come from Appveyor) to Travis (or
vice versa) to know if all platforms passed. With a PR, we can wait
for all platforms to pass and then click the button in the web
interface.

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

This is on by default on every repository that uses Travis. So yes.

> 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
> "

This is an option that every developer can set for themselves. By
default git will fast forward if possibly anyway, so I see no need to
enforce this and make the lives of developers harder if some important
hot fix did end up directly in master and is merged back into dev from
there (not that we want that, but if it does happen, forcing everyone
to rebase so they can continue to fast forward later just makes
everyones merges more difficult).

> 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

Maybe the dots would help readability, but since its just the dates
from lower to higher precision, I don't think it's very error prone
when typing. After all, I don't think "2 0 1 6 ...", but I think "this
year on may 21 at 5 past 6 pm" and then I just write it down. I feel
this isn't any harder to remember than an arbitrary SVN commit id.

> 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
>

This is possible to set up, and I agree we want some identifier for
unofficial builds, but I'm not convinced it's worth including branch
name and git user as well, since that can be easily checked from the
history on Github by just going to the commit hash.

> > 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

The branch@ is necessary because a) that's just how the git binary
works and b) you cannot uniquely identify commits by timestamp across
branches. I don't understand the point about graphs and reports - this
command should not appear in any report or graph, it is the command
that a VM developer would use to go to a specific timestamp, there is
not reason for this to be used in reporting...

Best,
Tim