<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font size="+1">Hi Eliot,<br>
<br>
...snip...</font>
<blockquote type="cite"
cite="mid:CAC20JE2PsZckr5BAzx-oKbGN47p3T4+WwwZ_1BwXeB0jOe2_LA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_default" style="font-size:large"> *BUT* (and
it's a big BUT) only if the test signals can be seen.<br>
</div>
</div>
</div>
</blockquote>
<font size="+1">...snip...</font><br>
<br>
<blockquote type="cite"
cite="mid:CAC20JE2PsZckr5BAzx-oKbGN47p3T4+WwwZ_1BwXeB0jOe2_LA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<font size="+1">Fully agree. I never know what to make of the report
that goes to the list. An I would be frustrated searching the
problem with that little information.<br>
<br>
What if Squeak's TestRunner iterates over the packages and on
each failure writes a text file with the packages's name. Jenkins
appends the directory list of these files to the mail going to
Squeak dev.<br>
<br>
Sorry I know nothing about Squeak's build system but at my
employer ASCII files are what binds the system tests together.
Audio processing, GUI, hardware, different cultures, different
programming languages, incompatible tools, but we get one detailed
report where we can see the single test that failed.<br>
</font><br>
<blockquote type="cite"
cite="mid:CAC20JE2PsZckr5BAzx-oKbGN47p3T4+WwwZ_1BwXeB0jOe2_LA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<br>
<font size="+1">No, 'This specific build has failed' please. Even
with a few builds you usually start looking at the wrong end. At
least I do.<br>
<br>
Cheers,<br>
<br>
Herbert<br>
</font><br>
<blockquote type="cite"
cite="mid:CAC20JE2PsZckr5BAzx-oKbGN47p3T4+WwwZ_1BwXeB0jOe2_LA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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" moz-do-not-send="true"><squeak-dev-bounces@lists.squeakfoundation.org></a>
im Auftrag von Chris Muller <a
href="mailto:asqueaker@gmail.com"
target="_blank" moz-do-not-send="true"><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" 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-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"
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-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>
</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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<br>
</body>
</html>