<div dir="ltr"><div dir="ltr">Hi Christoph,<div></div></div><div dir="ltr"><br></div><div>(sorry for so much traffic from me today folks!)</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="m_438235888551424676gmail-m_5710024722437358920divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr"><p><span>And that's why - sorry for rolling out my old chestnut again - I still do believe that a git-based workflow could make us as a community more efficient.</span></p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="m_438235888551424676gmail-m_5710024722437358920divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr"><p><span>I don't question that manual testing is great, and I don't question that quality can increase if you give your patches time for maturing, but when I compare the resulting workflow to the "mainstream" workflow that I can use anywhere on GitHub, I repeatedly
 have the dissatisfying feeling that the inbox/trunk workflow is so slow that it ruins all the efficiency from the Smalltalkish development workflow (which, however, unquestionably outperforms the "mainstream" workflow in a dead, non-live UI without first-class
 objects for code and tools!).</span></p></div></div></blockquote><div>I hear you, and I do think the video-game-fragathon-free-for-all style ;) might be... <i>interesting</i> to try out, IF there would not be permanent consequences from such an experiment in terms of our current Monticello implementation, which keeps the entire, ever-growing database of ancestry in RAM.  We currently can't afford to make "proposals" or have "dev discussions" there.  (Honestly, it seems like there's a good chance for that to be fixable -- some safe, backward-compatible way to trim the ancestry in memory -- but, TMK no attempts (other than MCInfoProxy) have so far been made at addressing it, but that's another discussion...).<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="m_438235888551424676gmail-m_5710024722437358920divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
<p></p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="m_438235888551424676gmail-m_5710024722437358920divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
<p><span>This might apply most significantly to small changes that would form a PR of two or three commits in a git project because our inbox workflow does not scale so well for changes of such extent. </span></p></div></div></blockquote><div>An Inbox repository pane docked on a tab in your IDE could go a long way toward simulating the dynamism of such a workflow -- some hot buttons to merge, unmerge, Reparent any versions in the Inbox -- does it matter if it came that way vs. "Update Squeak"?.  It could help it feel a lot more integrated.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="m_438235888551424676gmail-m_5710024722437358920divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr"><p><span>I do not know how many hours I already have spent on fixing
 the ancestry of my versions, comparing them to their ancestors, or re-uploading them, but it has definitively been too many hours ...</span></p></div></div></blockquote><div>It sounds like you're burning time there friend.  ;)  All that's necessary is to base off _some_ version in trunk (it can be old).  When it's integrated, the integrator will (should!) use the "Reparent" button to sculpt the ancestry appropriately for the trunk (<u><i>we need an ancestor selector on the commit dialog!)</i></u>  And this does touch on one reason I'm skeptical of the active-commit git-style workflow -- the overhead.  When I'm spending my time writing version notes, committing and updating, <i>I'm not writing code</i>.  With everyone doing it, everyone must constantly merging everyone elses' active-committal style, and if they're not really tested (<i>"eh, fix later!"</i>) then, at least in a live Smalltalk IDE with dependency on that code to your actual ability to work, -- as you encountered the other day with Tobias' commit -- it becomes worthy to scrutinize the "efficiency" of this methodology to ensure it's real and not only perceived.  Making a commit "feels" productive, but the extra efficiency from this methodology can only be realized <u>when and if</u> it's actually consumed by someone else <u>and</u> it was of good enough quality to boost their development.  But, our community is small, and busy.<br></div><div><br></div><div>By contrast, when I know its a steady-drip of quality commits, I have no qualms about clicking "Update Squeak".  I'm confident it'll be a positive click, and not a sideways or even risky click, because I know it's tested upgrades.</div><div><br></div><div>If you decide you're interested in addressing some of our IDE's limitations in conjunction with an explicit proposal for tweaking us toward more dynamism, I promise I'll at least be open-minded about it.  But, I may have some questions...  :/</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="m_438235888551424676gmail-m_5710024722437358920divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
<p><span style="font-size:12pt">Did someone ever investigate this question seriously by doing a study or so? I would really find the results interesting.</span></p></div></div></blockquote><div>   <a href="https://en.wikipedia.org/wiki/Capability_Maturity_Model#Maturity_models" target="_blank">https://en.wikipedia.org/wiki/Capability_Maturity_Model#Maturity_models</a><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="m_438235888551424676gmail-m_5710024722437358920divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr"><p><br></p>
<p><span><br>
</span></p>
<p><span>Best,</span></p>
<p><span>Christoph</span></p>
<br>
<div style="color:rgb(0,0,0)">
<hr style="display:inline-block;width:98%">
<div id="m_438235888551424676gmail-m_5710024722437358920divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>><br>
<b>Gesendet:</b> Dienstag, 29. September 2020 01:00 Uhr<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] tedious programming-in-the-debugger error needs fixing</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">On Mon, Sep 28, 2020 at 10:07 AM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div style="font-size:large">Hi Christoph,<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de" target="_blank">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div id="m_438235888551424676gmail-m_5710024722437358920gmail-m_-7091346116635287464gmail-m_2381582035141866110divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p>Hi Eliot,</p>
<p><br>
</p>
<p>I'm very sorry for this bug, which was so unnecessary because my image has still a gigantic working copy ...! <span>Tools-ct.988 should fix the issue, I tested it in a fresh trunk image. But it would be probably better if you could test it yourself, too.
 ;-)</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div style="font-size:large">No need to apologise.  It's an easy mistake, and you fixed it.  As long as we're all patient with each other and take responsibility (Andreas said "if you break it, you fix it") we're going to get along fine and be collectively
 productive.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>The following is not addressed to Christoph or his commit, but to Eliots comment, above:  Patience should begin within our development methodology.  The words above are correct and sweet, and I agree with them, but I feel the need to caution against the
 implication that "everything's great as long as you fix it <i>afterward</i>."  Maybe for git-based projects, a
<i>commit-first, fix-later</i> strategy is what that culture likes and that system can support, but it's not a good fit for Squeak's trunk.  I believe Andreas understood this, and he indicated that "breaking the trunk is generally frowned upon."</div>
<div><br>
</div>
<div>When it comes to code less than 24 hours old, no matter how simple it seems, chances are about 80% that a subsequent "oops, sorry" commit will need to follow.  With "older," (e.g., even only just 48 hours!)
<u>tested</u> code, that chance drops significantly.  Patience.  Restraint.  Please.  :)  Let our methodology put time to work
<i>for</i> us, by living with our changes for a bit (as, it sounds like, Christoph did!) and witness them work in context.  Maybe not this time, but
<i>generally, </i>you'll have a gist enough to know whether it should be loaded and tested separately in a clean trunk first.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>  Chris</div>
</div>
</div>
</div>
</div>
</div>
</div>

</blockquote></div></div>