<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Hi all,</p>
<p><br>
</p>
<p>let me just throw in the cost curve (Barry Boehm I think). A bug
gets exponentially more expensive, the later it's found. And the
fact that for x bugs found during testing you can be sure to
deliver n*x bugs to the customer. n maybe <<1 but still.
Don't know the source of this any more.<br>
</p>
<p><br>
</p>
<p>I'm bitten by a workflow of quick commits (we are also using Git)
as a QA person in my day job where they also add hasty reviews to
the quick commits. So I kind of cringed when I read Christoph's
post :-).</p>
<p><br>
</p>
<p>Still a complex or tedious workflow is also bad for quality and
productivity so that's the point of the post I fully agree with.</p>
<p><br>
</p>
<p>I'm too far away from Squeak but would it be a possibility to
have small commits in Git (or elsewhere) and consolidated bigger
ones for a proper ancestry? At least we need to be very careful
when changing the community process.</p>
<p><br>
</p>
<p>Best regards,</p>
<p><br>
</p>
<p>Herbert<br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 29.09.20 um 01:38 schrieb Thiede,
Christoph:<br>
</div>
<blockquote type="cite"
cite="mid:23476c3e0a68492c8cc917c38ba2c9d4@student.hpi.uni-potsdam.de">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" 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>Maybe for git-based projects, a commit-first,
fix-later strategy is what that culture likes and that
system can support, but it's not a good fit for Squeak's
trunk.</span></p>
<p><span><br>
</span></p>
<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>
<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>
<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. 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>
<p><span><br>
</span></p>
<p><span>Did someone ever investigate this question seriously by
doing a study or so? I would really find the results
interesting.</span></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 tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>Von:</b>
Squeak-dev
<a class="moz-txt-link-rfc2396E" href="mailto:squeak-dev-bounces@lists.squeakfoundation.org"><squeak-dev-bounces@lists.squeakfoundation.org></a> im
Auftrag von Chris Muller <a class="moz-txt-link-rfc2396E" href="mailto:asqueaker@gmail.com"><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"
moz-do-not-send="true">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" moz-do-not-send="true">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="gmail-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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
</body>
</html>