[squeak-dev] Development methodology (was: tedious programming-in-the-debugger error needs fixing)

Marcel Taeumel marcel.taeumel at hpi.de
Tue Sep 29 12:57:38 UTC 2020


Hi Christoph.

> 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

>From what I experienced so far, its mostly a matter of time and people. Those occasional hiccups with our inbox don't change the fact that reviews take time and effort. Having a fancy "auto-merge this pull request because CI says it is okay" won't make it better. Maybe even worse.

Time and people. Or the other way round. ;-)

And we cannot just promote all frequent contributors to be Trunk committers to speed up the process. It still takes a lot of time until new Squeaker's understand the essence of what Chris was talking about here: http://forum.world.st/tedious-programming-in-the-debugger-error-needs-fixing-tp5109568p5122658.html [http://forum.world.st/tedious-programming-in-the-debugger-error-needs-fixing-tp5109568p5122658.html] --- That is, the kind of discipline and patience that even experienced Squeak's (and Trunk committers) struggle with from time to time.

One cannot just wrap Git and GitHub (tools) around some project and expect that problem magically go away. Just look at the OpenSmalltalk VM repo: https://github.com/OpenSmalltalk/opensmalltalk-vm [https://github.com/OpenSmalltalk/opensmalltalk-vm] --- Many open issues and pull requests, some of them are several years old.

Best,
Marcel

Am 29.09.2020 01:38:22 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
> 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.

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.
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!).
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 ...

Did someone ever investigate this question seriously by doing a study or so? I would really find the results interesting.

Best,
Christoph

Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Chris Muller <asqueaker at gmail.com>
Gesendet: Dienstag, 29. September 2020 01:00 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] tedious programming-in-the-debugger error needs fixing
 
On Mon, Sep 28, 2020 at 10:07 AM Eliot Miranda <eliot.miranda at gmail.com [mailto:eliot.miranda at gmail.com]> wrote:

Hi Christoph,


On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de [mailto:Christoph.Thiede at student.hpi.uni-potsdam.de]> wrote:

Hi Eliot,

I'm very sorry for this bug, which was so unnecessary because my image has still a gigantic working copy ...! 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. ;-)

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.

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 afterward."  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.  I believe Andreas understood this, and he indicated that "breaking the trunk is generally frowned upon."

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!) tested code, that chance drops significantly.  Patience.  Restraint.  Please.  :)  Let our methodology put time to work for 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 generally, you'll have a gist enough to know whether it should be loaded and tested separately in a clean trunk first.

Cheers,
  Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200929/9c4fd350/attachment.html>


More information about the Squeak-dev mailing list