<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:large">Hi Herbert,<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 5:44 AM Herbert <<a href="mailto:herbertkoenig@gmx.net">herbertkoenig@gmx.net</a>> wrote:<br></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>
<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></div></blockquote><div><br></div><div class="gmail_default" style="font-size:large">Thanks, this accords with my experience. Thank you. It also is a strong argument for continuous integration and tests, *BUT* (and it's a big BUT) only if the test signals can be seen.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">So lumping lots of tests together so that the one persistently failing test marks the whole suite as having failed isn't helpful. For example, if our SUnit tests were grouped by package then we could see much sooner when a commit of a package broke something. Right now, with everything lumped together the fact that we have some failing tests (an inevitability in complex projects with lots going on, and long term issues that need long term actions to solve) obscures the test results, and means we're not able to use them as we should. If we broke out the test results in sub groups, and didn't report the overall signal, but emphasised the deltas between successive runs of individual groups, we would see when things break.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Right now the CI for VM builds aggregates in exactly this way so when I look in my email I see that the tests have failed (so what's new"). Well, yesterday I had time to look (I don't always) and found that the builds are OK up until a run of a build of a newspeak VM, and the VM build is OK, it is the Newspeak bootstrap that fals, and since Newspeak (I think I'm right in thinking) is no longer maintained, this is not a surprise.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">But instead of simply discarding the Newspeak build to get green tests again, better would be to </div><div class="gmail_default" style="font-size:large">a) not chain the builds so that an early failure prevents potentially successful subsequent builds, i.e. attempt to build everything</div><div class="gmail_default" style="font-size:large">b) report to the mailing list a message that specifies which builds have failed, so the subject line would be something like "Travis CI: M builds out of N have failed", not the depressing "the build has failed"</div><div class="gmail_default" style="font-size:large"><br></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><p>
</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 :-).<br></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></div></blockquote><div><br></div><div class="gmail_default" style="font-size:large">We have all the infrastructure we need in Monticello (it supports branching and merging, and multiple repositories). We even have something close to what you suggest in production, with release repositories that allow people to stay with e.g. squeak53, and we can push improvements and bug fixes there. But I agree, we want something like a high-frequency trunk and a low-frequency trunk. So we could implement e.g. treatedtrunk, and, say, automate pushing the 3 day, or 7 day old, trunk to treatedtrunk. It would be easy for those wanting a stable trunk process to stay with the treatedtrunk update stream, and to load from trunk the latest greatest that they really want, since the delta between treatedtrunk and trunk would be small, and the delta would be no more than a few days worth of commits.</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>
<p>Best regards,<br></p>
<p><br>
</p>
<p>Herbert<br>
</p>
<p><br>
</p>
<p><br>
</p>
<div>Am 29.09.20 um 01:38 schrieb Thiede,
Christoph:<br>
</div>
<blockquote type="cite">
<div id="gmail-m_-7838984820636082985divtagdefaultwrapper" 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 style="display:inline-block;width:98%">
<div id="gmail-m_-7838984820636082985divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><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-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<div id="gmail-m_-7838984820636082985gmail-m_-7091346116635287464gmail-m_2381582035141866110divtagdefaultwrapper" dir="ltr">
<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></fieldset>
<pre></pre>
</blockquote>
</div>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>