{"action":"created","issue":{"url":"https://api.github.com/repos/dolphinsmalltalk/Dolphin/issues/27","labels_url":"https://api.github.com/repos/dolphinsmalltalk/Dolphin/issues/27/labels{/name}","comments_url":"https://api.github.com/repos/dolphinsmalltalk/Dolphin/issues/27/comments","events_url":"https://api.github.com/repos/dolphinsmalltalk/Dolphin/issues/27/events","html_url":"https://github.com/dolphinsmalltalk/Dolphin/issues/27","id":125765142,"number":27,"title":"Formulate a Dolphin workflow","user":{"login":"objectarts","id":10649476,"avatar_url":"https://avatars.githubusercontent.com/u/10649476?v=3","gravatar_id":"","url":"https://api.github.com/users/objectarts","html_url":"https://github.com/objectarts","followers_url":"https://api.github.com/users/objectarts/followers","following_url":"https://api.github.com/users/objectarts/following{/other_user}","gists_url":"https://api.github.com/users/objectarts/gists{/gist_id}","starred_url":"https://api.github.com/users/objectarts/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/objectarts/subscriptions","organizations_url":"https://api.github.com/users/objectarts/orgs","repos_url":"https://api.github.com/users/objectarts/repos","events_url":"https://api.github.com/users/objectarts/events{/privacy}","received_events_url":"https://api.github.com/users/objectarts/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2016-01-09T15:35:47Z","updated_at":"2016-01-27T17:37:32Z","closed_at":null,"body":"We need to come up with a workflow for D7 that caters easily for the  following:\r\n\r\n* There will likely be two classes of users. Those who wish to work on the core Dolphin product (let's call them **coredevs**) and those who want to treat Dolphin as a tool to build other projects (called them **userdevs**).\r\n\r\n* Users may be in both categories (**userdevs** may make changes to the core system during their project work that they can easily contribute back as **coredevs** into the Core).\r\n\r\n* We can assume that **coredevs** will always use GitHub. **userdevs** may not. They may chose to use another source control system like STS, git, mercurial or something else.\r\n\r\n## Workflow A - Emulate D6\r\nOne proposal is to emulate the Dolphin 6 workflow. D6 used a read-only \"template\" core image stored in _Program Files_ that could be duplicated (unlocked) into any **\\User** directory. All core packages would exist in the image but when externalised from it (by package save) would appear as a directory structure under **\\User**. Core Dolphin packages would appear under **\\User\\Dolphin** and user packages would be, say, under **\\User\\My Projects**. \r\n\r\nTypically the **userdev** would externalise packages from their image and manually place them into a SCCS. In such cases they would probably write a load script to install their project packages into a new image when required. The DPRO STS system would help greatly in this respect since it has the concept of **Projects** that can load versions of many packages to bring any project into the image.\r\n\r\nA **userdev** working on multiple projects at once might choose to work in a single image, or multiple images in **\\User** or maybe in multiple images in separate user directories (**\\User1**, **\\User2**).\r\n\r\n### Workflow A - for D7\r\n\r\n1) The Dolphin core is downloaded into **\\Dolphin** (by **coredevs**) from GitHub or (by **userdevs**) as a ZIP with the images prebuilt. GitHub users will have to boot the images before use.\r\n\r\n2) A working DPRO image is copied to **\\User**. This effectively (as it stands now) makes Dolphin think that all the core packages actually live under **\\User\\Core**. The link with the original **\\Dolphin\\Core** directory where the Git information is held is lost.\r\n\r\n3) A **userdev** creates a project and the package source is held in **\\User\\Projects**. This may be a Git directory if the **userdev** is using Git/GitHub or it might be held in STS. \r\n\r\n4) Any changes that are made to the Dolphin core will be saved to PAX files under **\\User\\Core**. If the Source Browser is used to write out changes only, then it is easy to see what is changed because only the changed packages will be present.\r\n\r\n5) A **userdev** reloading a project will have to invent a loading scheme (ST fileIn?) to load all the changes into a virgin image. Of course, STS would make this significantly easier.\r\n\r\n6) A **userdev** who is also a **coredev** will want to apply the changes saved under **\\User\\Core** back into the **\\Dolphin\\Core** directory (the GitHub repository) and then submit a pull request. This is the tricky and untidy bit. Two possibilities come to mind:\r\n\r\na) Copy the **\\User\\Core\\** sub-directories to **\\Dolphin\\Core** and then commit them using Git as normal.\r\n\r\nb) Copy a virgin DPRO image from **\\Dolphin** to **\\User**. Load the project contents under **\\User\\Core** into this image and then copy the DPRO image back to **\\Dolphin**. The Source Browser can then save out the core changes, which can be committed as usual.\r\n\r\nI think this flow will work, although the copying of core information back and forth between **\\User** and **\\Dolphin** directories is unpleasant. It also occurs to me that such a flow will probably work better using STS as a sort of intermediate repository between the image and GitHub (or any other SCCS). This is not ideal because it would be yet another tool barrier for a new user to learn when getting started. This might not be appreciated if the **userdev** just wants to use GitHub anyway. Some additional Git related features in STS might make this more palatable.\r\n\r\n## Workflow B - Users never change Dolphin core\r\n\r\nThis workflow is identical to Workflow A above except it avoids the tricky moving of modification back from the **\\Work** directory structure back to **\\Dolphin** by _disallowing_ them. So as above except:\r\n\r\n1) Whenever a **userdev** find that a change is needed to the Dolphin core files they must stop and return to the **\\Dolphin** directory and make the changes in a (DPRO) image there.\r\n\r\n2) The Source Browser is used to emit the core changes under **\\Dolphin** and GitHub can then be used to commit them and submit a pull request (if the this is a **coredev** role).\r\n\r\n3) A new core DPRO image is built using **BootDPRO** or **BootAll** and copied to the **\\Work** folder.\r\n\r\n4) From there, the **userdev** reloads projects and continues work with the new Dolphin core changes in place.\r\n\r\nThis is perhaps a neater workflow that A, especially as **userdev** changes to the Dolphin core should be rare. Remember, using Dolphin's package system and _loose methods_ it is still possible to extend the core classes without having to modify the core packages.\r\n\r\n## Workflow C - Clone Dolphin Core for each project\r\n\r\nThe idea here is to have a full **\\Dolphin** installation for each project (or set of projects).\r\n\r\n1) The Dolphin core image is unzipped or cloned into **\\User\\Dolphin**. Again **coredevs** must use GitHub and will have to build the product images using BootAll.cmd.\r\n\r\n2) User project packages are held under **\\User\\Dolphin\\Projects** and sit alongside the **Core** directory. The _.gitignore_ file will have to be modified in **\\User\\Dolphin** to ignore files under **Projects** - these would be cloned from a separate user GitHub repository (if using GitHub).\r\n\r\n3) During development the user makes changes to his/her own packages and possibly to core packages.\r\n\r\n4) The Source Browser is used to write out source changes to PAX files under **\\User\\Dolphin\\Projects** and **\\User\\Dolphin**. \r\n\r\n5) Git can then be used to push changes to the core and project repos separately.\r\n\r\n**The above workflows are proposals. Comments and alternative proposals are welcome.**\r\n\r\nOnce we have one (or maybe two) definitive workflows we should publish them on the Wiki."},"comment":{"url":"https://api.github.com/repos/dolphinsmalltalk/Dolphin/issues/comments/175762447","html_url":"https://github.com/dolphinsmalltalk/Dolphin/issues/27#issuecomment-175762447","issue_url":"https://api.github.com/repos/dolphinsmalltalk/Dolphin/issues/27","id":175762447,"user":{"login":"brunobuzzi","id":4719282,"avatar_url":"https://avatars.githubusercontent.com/u/4719282?v=3","gravatar_id":"","url":"https://api.github.com/users/brunobuzzi","html_url":"https://github.com/brunobuzzi","followers_url":"https://api.github.com/users/brunobuzzi/followers","following_url":"https://api.github.com/users/brunobuzzi/following{/other_user}","gists_url":"https://api.github.com/users/brunobuzzi/gists{/gist_id}","starred_url":"https://api.github.com/users/brunobuzzi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/brunobuzzi/subscriptions","organizations_url":"https://api.github.com/users/brunobuzzi/orgs","repos_url":"https://api.github.com/users/brunobuzzi/repos","events_url":"https://api.github.com/users/brunobuzzi/events{/privacy}","received_events_url":"https://api.github.com/users/brunobuzzi/received_events","type":"User","site_admin":false},"created_at":"2016-01-27T17:37:32Z","updated_at":"2016-01-27T17:37:32Z","body":"I will go with Workflow 3 the last mentioned by @objectarts or  @jgfoster. \r\nI do not think that changes in the Core are so frequent...may be in some special time it could be frequent but for now....\r\n"}}