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

[Ben Coman]

On Mon, May 23, 2016 at 3:58 PM, Tim Felgentreff
<timfelgentreff at gmail.com> wrote:
>
> 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.

cool.


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

I'm not sure I was clear.  This would be *only* for the "master"
branch.  In a case where a hotfix ended up applied direct to master,
it could be merged from there into dev, and then dev merged back into
master, and that last merge would be fast forward anyway (IIUC??)

My idea was to ensure that merges from dev into master had *identical*
hashes, rather than getting a new hash from a merge-commit.   But
actually I admit I'm not sure whether that has any practical value.
It just seemed like a nice idea.


[relocated higher in post]
>> > 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...

Whoops. I misunderstood.  I thought you'd literally meant branches
that were manually created like
    git branch 'mybranch@{1979-02-26 18:30:00}'

Now I understand you meant like this...
    http://www.bramschoenmakers.nl/en/node/645

Any concerns with the 90 day limit with that...?
   http://blog.endpoint.com/2014/05/git-checkout-at-specific-date.html
Would there a utility script to help with the more complicated form
using "--before"?


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

fair enough, but in light of using "git checkout dev@{timestamp}"
it might be nice to be able to cut-n-paste the timestamp output
from the -version flag.  I found checkout worked with a timestamp
like YYYYMMDD-HH:mm:ss , but not like YYYYMMDD-HHmmss
nor YYYYMMDDHHmmss.

I guess since you need to know the branch the timestamp belongs to,
this form of checkout is only applicable to the 'dev' branch, which is fine
if its the only branch using that form of version string, but highlights
the usefulness for unofficial builds to include the git hash in their -version.

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

Good point.

cheers -ben