
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">forget it, I renounce to try to explain why from maintainability/management point of view is a lot better to keep all sources together. </div><div class="">Obviously, I’m wrong, and the situation we have today is ideal. </div><div class=""><br class=""></div><div class="">Esteban</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 7 Jun 2017, at 21:43, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" class="">nicolas.cellier.aka.nice@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">2017-06-07 16:45 GMT+02:00 Esteban Lorenzano<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:estebanlm@gmail.com" target="_blank" class="">estebanlm@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"> <br class=""><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 7 Jun 2017, at 15:15, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank" class="">nicolas.cellier.aka.nice@gmai<wbr class="">l.com</a>> wrote:</div><br class="gmail-m_-3915654541088853328m_2416585979958534157Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">2017-06-07 14:32 GMT+02:00 Esteban Lorenzano<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:estebanlm@gmail.com" target="_blank" class="">estebanlm@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class="">Hi Dave, list<br class=""><br class="">I want to commit some changes to OSProcessPlugin.<br class="">Can I have rights to that repository?<br class=""><br class="">thanks,<br class="">Esteban<br class=""><br class="">ps: I need to insist in the necessity of having all VM plugins (the “official” ones: those who are compiled with the osvm builds) in the same place. Otherwise this is a horrible (and irreproducible) process.<br class=""><br class=""></blockquote></div><br class=""></div><div class="gmail_extra">Hi Esteban,<br class=""></div><div class="gmail_extra">why not reproducible?<br class=""></div><div class="gmail_extra">Isn't it manageable with a Monticello Configuration Map (.mcm) as David suggested, or a Metacello ConfigurationOf... for being more pharo-to-date?<br class=""></div></div></div></blockquote><br class=""></div><div class="">because is a pain to maintain, and having different repository services makes you needing to thrust in different providers status, and then if you want to work offline you need to take a copy of each repository which are dispersed all around the world.</div></div></blockquote><div class=""><br class=""></div><div class="">The  location are relatively stable so far (one move from<span class="Apple-converted-space"> </span><a href="http://www.squeacksource.com/" target="_blank" class="">www.squeaksource.com</a><span class="Apple-converted-space"> </span>to<span class="Apple-converted-space"> </span><a href="http://source.squeak.org/" target="_blank" class="">source.squeak.org</a><span class="Apple-converted-space"> </span>for VMMaker a few years ago).<br class=""> <br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class="">I just lost 3 hours of my life trying to figure out which version of OSProcessPlugin was the correct one, then looking for the correct repository, etc. </div><div class="">This wouldn’t happened if all used plugins are maintained together. </div><div class=""><br class=""></div></div></blockquote><div class="">... Nor if you would use either a mcm or Metacello configuration.<br class=""><br class=""><div class="">Speaking of repository map, I just checked the status of Pharo 6, and it does not look more simple:<br class=""><br class=""> <span id="cid:ii_15c83e11c0588f60"><Capture d’écran 2017-06-07 à 20.36.36.png></span><br class=""></div><div class=""><br class=""></div></div><div class="">Naming branches and tagging stability is a different problem than repository location.<br class=""><br class=""></div><div class="">For OSProcess, there are only two branches (interpreter and oscog/spur), and history is quite linear (just bug fixes). So the policy is: load latest, run regression tests, revert only if something goes wrong.<span class="Apple-converted-space"> </span><br class=""><br class=""></div><div class="">It's true that in MC, explicitely naming branches is optional, but we can...<br class="">It's just a convention (like naming master trunk cog or anything else is just a convention in git). I'm not sure we really need it yet for plugins, new features are scarce.<br class=""><br class=""></div><div class="">The main difference is not about branches, it's more about integration of tools, issues/wiki/PR/CI.<br class=""></div><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""></div><div class="">btw (advocating for the way I would like to have things) this wouldn’t even be necessary if all packages needed would be versioned along the platform sources, using filetree format… then having the clone of your desired version you would be sure to have also the correct VMMaker AND plugin versions… but I know this way of sorting things is too much to ask, so I would be happy if all packages are *at least* in the same place.</div><div class=""><br class=""></div><div class="">Esteban</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""><div class="">For having worked a bit on the pharo-vm two years ago, the workflow was horrible.<br class=""><br class="">We had the workspace provided by image state - which is like a mixture of working copy (dirty with unpublished changes) + staging area (cherry picking thru MC GUI), eventually with branches/stach saved in package-cache, or in other MC repositories.<br class=""><br class="">This was concurrencing the working copy on disk, which was often out of sync, and conflicting.<br class=""><br class="">Branches in MC repositories had to be synced manually with git branches (I used my own Smalltalkhub repository for my own experiments with many feature branches, plus official VMMaker repo which I regularly tried to merge, plus pharo VM github repo).<br class=""><br class="">Each pull request was rotting immediately due to MC metadata and incomprehensible policy of ignoring the merge tool provided by Thierry Goubier (which was working quite smoothly).<br class="">And there were bugs introduced by pharo in MC, plus bugs of file names too long, and I probably forget other annoyances.<br class=""><br class=""></div><div class="">So it was a nice experiment for learning, but clearly not mature.<br class=""></div><div class=""><br class=""></div><div class="">Shifting entirely to git would reduce the complications a bit. and I promise I will test the new git-based-in-image-version-control-tools provided by Pharo and help getting closer to your ideal world.<br class="">But what about the status of image changes? Or is the image a pseudo file system?<br class="">Anyway, you know it will take time to reach the maturity and smoothness of MC. MC rocks (at least in Squeak).<br class=""><br class=""></div></div><div class="">Stability of tools apart, for OSProcessPlugin, we have a different case: the manager wants to control integration of change requests. How is it going to work with a single repository? Or is it something you want to change too?</div></div></div></blockquote></div><br class=""></div></body></html>