On Sun, Jun 4, 2017 at 1:10 AM, Eliot Miranda <[hidden email]> wrote:
So we should do this under the OpenSmalltalk-VM project?
One extra thing, there feels like as explosion of *src* folders in the root directory. This could be an opportunity to clean these up into a subdirectory (and a side benefit is I can experiment without touching existing srcs) So I'd like to run a possible structure past you... opensmalltalk-vm/ VMMaker/ mc-mirror/ #versioned in filetree format generated/ #versioned - initial generation checked into a separate branch until manual review and merge. src/ stacksrc/ nsspursrc/ nsspur64src/ nsspurstacksrc/ nsspurstack64src/ spursrc/ spur64src/ spurstack64src/ spurstacksrc/ spurlowcodesrc/ spurlowcodestacksrc/ spurlowcode64src/ spurlowcodestack64src/ spursistasrc/ spursista64src/ build/ Makefile CI-build-scripts.sh generated.squeak/ #not versioned, build host only src/ spursrc/ spur64src/ ...etc generated.pharo/ #not versioned, build host only src/ spursrc/ spur64src/ ...etc When http://source.squeak.org is updated, this would trigger the CI copy it into "mc-mirror" then build both "generated.squeak/" & "generated.pharo/". The two would be cross compared and if identical, then "generated/" would be updated with substantive changes only. Both "mc-mirror/" and "generated/" would be checked into a "source-generation" branch that would kick off a regular CI vm build and test (only if there were substantive changes). The advantage being that github comments can be attached to individual lines of code to facilitate public review and discussion. After manual review, the source-generation branch can be merged via PR to perform the regular CI test run inclusive of any platform changes. cheers -ben |
On Tuesday 13 June 2017 11:09 AM, Ben Coman wrote: > > One extra thing, there feels like as explosion of *src* folders in the > root directory. This could be an opportunity to clean these up into a > subdirectory (and a side benefit is I can experiment without touching > existing srcs) This is due to all variations sharing the same branch ("Cog"). Now that all sources are in git, these variations can be moved into their own branches: master (Sista?), Spur, Cog, Stack? and use Tags to mark releases like Squeak5, Pharo6 etc. This will reduce clutter and make it easy for CI builds and tests. Regards .. Subbu |
On Wed, Jun 14, 2017 at 1:57 AM, K K Subbu <[hidden email]> wrote:
I expect there will be strong resistance to that. It would be hell to track. Those folders are generated from the same Smalltalk code base, just different options. We want the CI to build all variations in one run to verify changes don't break any of them. Technically "Stack" is outside "Cog", but I guess its more than "this is where we are concentrating on developing Cog" with any changes to "Stack"-only code being a side-effect. While I believe it would be good to have more short lived branches (e.g. not a long-lived "Sista" branch, but a "this-new-feature-for-Sista" branch that goes away once CI tests pass and PR is integrated) its hard to change habits and while the existing might not scale, its working for the number of main collaborators we currently have. and use Tags to mark releases like Squeak5, Pharo6 etc. This will reduce clutter and make it easy for CI builds and tests. Since tags don't show up in the graph view... I believe we need we need branches to mark major versions and tags marking point releases. but just for human tracking, not having any impact on CI builds. cheers -ben |
In reply to this post by Ben Coman
On Tue, Jun 13, 2017 at 1:39 PM, Ben Coman <[hidden email]> wrote:
btw, I'd set this up so that updating "generated/" is a separate script from updating together "mc-mirror/" and "generating.squeak/" to help manually investigate differences between a "generated/" and new "generated.squeak/". cheers -ben
|
Free forum by Nabble | Edit this page |