Minutes of the Meeting to Discuss Moving Cog to Github

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Minutes of the Meeting to Discuss Moving Cog to Github

Eliot Miranda-2
 
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


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

  • Make WebHooks for Commit Notifications available to anyone who wants them.
  • 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
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of the Meeting to Discuss Moving Cog to Github

Tudor Girba-2

Hi,

Thank you very much to everyone involved for making this happen!

Cheers,
Doru


> On May 20, 2016, at 7:28 PM, Eliot Miranda <[hidden email]> 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
>
> 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
> • Make WebHooks for Commit Notifications available to anyone who wants them.
> • 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

--
www.tudorgirba.com
www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

Reply | Threaded
Open this post in threaded view
|

Re: Minutes of the Meeting to Discuss Moving Cog to Github

Juan Vuletich-3
In reply to this post by Eliot Miranda-2
 
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

On 5/20/2016 2:28 PM, Eliot Miranda 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


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

  • Make WebHooks for Commit Notifications available to anyone who wants them.
  • 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

Reply | Threaded
Open this post in threaded view
|

Re: Minutes of the Meeting to Discuss Moving Cog to Github

Eliot Miranda-2
 
Hi Juan,

On Fri, May 20, 2016 at 12:57 PM, Juan Vuletich <[hidden email]> wrote:
Hi Folks,

This is just great!

I assume builds will include:
- V3, Cog, 32bitBinaries
- Spur32, Cog, 32bitBinaries
- Spur64, Cog, 64bitBinaries

Yes.
 

Would it also be possible to include:
- V3, Stack, 32bitBinaries
- Spur32, Stack, 32bitBinaries
- Spur64, Stack, 64bitBinaries
?

I think so.  Tim F tells me that Github support for open source projects is free, including disk space, so there's nothing to stop us including a comprehensive suite of VMs.
 
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.

Indeed, I hope that with the new repository it will be much easier for the people who got the VM working on iPad to integrate their changes.  It should also be possible to have Linux ARM v6 (Pi) and Linux ARM v7 (Android) VMs.
 

Thanks you all!
Juan Vuletich


On 5/20/2016 2:28 PM, Eliot Miranda 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


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

  • Make WebHooks for Commit Notifications available to anyone who wants them.
  • 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




--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

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

Torsten Bergmann
In reply to this post by Eliot Miranda-2
 
Cool to see that happen now. Future now looks even brighter.
Big, big thanks to anyone who was/is involved!!!

Some questions:

  1. Whoever has access for Squeak: is it planned to update http://www.squeakvm.org with that info?
  2. Will http://www.mirandabanda.org/files/Cog/VM/ stay and get updated with binaries or will
      these be hosted on GitHub in the future as well?
  3. Is there any effect on http://files.pharo.org/vm/ ?

Bye
T.
 
Gesendet: Freitag, 20. Mai 2016 um 19:28 Uhr
Von: "Eliot Miranda" <[hidden email]>
An: "Squeak Virtual Machine Development Discussion" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "Discussion of Cuis Smalltalk" <[hidden email]>, "Discusses Development of Pharo" <[hidden email]>, "The general-purpose Squeak developers list" <[hidden email]>
Betreff: [Pharo-dev] Minutes of the Meeting to Discuss Moving Cog to Github
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

 

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

  • Make WebHooks for Commit Notifications available to anyone who wants them.
  • 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
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of the Meeting to Discuss Moving Cog to Github

stepharo
In reply to this post by Eliot Miranda-2
 

Really nice!



Le 20/5/16 à 19:28, Eliot Miranda a écrit :
 


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


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

  • Make WebHooks for Commit Notifications available to anyone who wants them.
  • 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

Reply | Threaded
Open this post in threaded view
|

Re: Minutes of the Meeting to Discuss Moving Cog to Github

EstebanLM
In reply to this post by Eliot Miranda-2
 

On 20 May 2016, at 23:49, Eliot Miranda <[hidden email]> wrote:

Indeed, I hope that with the new repository it will be much easier for the people who got the VM working on iPad to integrate their changes.  It should also be possible to have Linux ARM v6 (Pi) and Linux ARM v7 (Android) VMs.

For iPad, sources were working a couple of years ago and we never comeback… make it work should be not hard but once integrated with John’s work on cocoa we'll need to have a new look… 

Esteban
Reply | Threaded
Open this post in threaded view
|

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

EstebanLM
In reply to this post by Torsten Bergmann
 

On 21 May 2016, at 03:22, Torsten Bergmann <[hidden email]> wrote:

 3. Is there any effect on http://files.pharo.org/vm/ ?

there should not be any change there… once reunified sources we will continue producing Pharo VMs and offering them in the usual mechanisms :)

Esteban

Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Torsten Bergmann
 


On Fri, May 20, 2016 at 6:22 PM, Torsten Bergmann <[hidden email]> wrote:
 
Cool to see that happen now. Future now looks even brighter.
Big, big thanks to anyone who was/is involved!!!

Some questions:

  1. Whoever has access for Squeak: is it planned to update http://www.squeakvm.org with that info?

Thanks for the reminder.  We will make that happen.
 
  2. Will http://www.mirandabanda.org/files/Cog/VM/ stay and get updated with binaries or will
      these be hosted on GitHub in the future as well?

I expect everything will migrate to Github.  But hopefully links can be designed so that links from mirandabanda.org point to the relevant artefacts on github.com/OpenSmalltalk/vm.
 
  3. Is there any effect on http://files.pharo.org/vm/ ?

Bye
T.
 
Gesendet: Freitag, 20. Mai 2016 um 19:28 Uhr
Von: "Eliot Miranda" <[hidden email]>
An: "Squeak Virtual Machine Development Discussion" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>, "Discussion of Cuis Smalltalk" <[hidden email]>, "Discusses Development of Pharo" <[hidden email]>, "The general-purpose Squeak developers list" <[hidden email]>
Betreff: [Pharo-dev] Minutes of the Meeting to Discuss Moving Cog to Github
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

 

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

  • Make WebHooks for Commit Notifications available to anyone who wants them.
  • 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




--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of the Meeting to Discuss Moving Cog to Github

Ben Coman
In reply to this post by Eliot Miranda-2

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

On Sat, May 21, 2016 at 1:28 AM, Eliot Miranda <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of the Meeting to Discuss Moving Cog to Github

timfelgentreff

Hi Ben,

On 21 May 2016 at 19:44, Ben Coman <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of the Meeting to Discuss Moving Cog to Github

Ben Coman

On Mon, May 23, 2016 at 3:58 PM, Tim Felgentreff
<[hidden email]> wrote:

>
> Hi Ben,
>
> On 21 May 2016 at 19:44, Ben Coman <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Minutes of the Meeting to Discuss Moving Cog to Github

Ben Coman
In reply to this post by Eliot Miranda-2

On Sat, May 21, 2016 at 1:28 AM, Eliot Miranda <[hidden email]> 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
>
[snip]
> 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.

I thought this might be of interest since it says 'SVN- or CVS-style
keyword expansion is often requested by developers used to those
systems..."
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion

cheers -ben