[squeak-dev] tedious programming-in-the-debugger error needs fixing

karl ramberg karlramberg at gmail.com
Tue Sep 29 08:50:55 UTC 2020


I thought Trunk was for bleeding edge development. And that the bleeding
occurs when stuff needs further fixing.
We need a middle ground so that the inbox doesn't just become a dead end of
bit rotted improvements and fixes.

Best,
Karl


On Tue, Sep 29, 2020 at 8:38 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi all!
>
> +1 to Eliot
> +1 to Chris
>
> +1000 to our community! :-)
>
> Happy programming. Happy squeaking.
>
> Best,
> Marcel
>
> Am 29.09.2020 01:01:14 schrieb Chris Muller <asqueaker at gmail.com>:
> On Mon, Sep 28, 2020 at 10:07 AM Eliot Miranda <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> 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/7beb012d/attachment.html>


More information about the Squeak-dev mailing list