tedious programming-in-the-debugger error needs fixing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

tedious programming-in-the-debugger error needs fixing

Eliot Miranda-2
Hi All,

    if in a block in the debugger and one redefines the method, the debugger says "I will need to go back to the method that defined this block" or some such. If there is a syntax error in the new code one is trying to compile then the original method is displayed, the syntax error is displayed in that original text, and one's edited text is lost.
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: tedious programming-in-the-debugger error needs fixing

Christoph Thiede

Hi Eliot,


Can you give an exact step-by-step example to reproduce?

It appears that the context is reset before compiling the method, so when you have a syntax error, the execution will have been reset. However, I could not find a scenario in which the syntax error is displayed in the original text ...

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Montag, 6. Januar 2020 22:18:02
An: The general-purpose Squeak developers list
Betreff: [squeak-dev] tedious programming-in-the-debugger error needs fixing
 
Hi All,

    if in a block in the debugger and one redefines the method, the debugger says "I will need to go back to the method that defined this block" or some such. If there is a syntax error in the new code one is trying to compile then the original method is displayed, the syntax error is displayed in that original text, and one's edited text is lost.
_,,,^..^,,,_
best, Eliot


Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: tedious programming-in-the-debugger error needs fixing

Frank Shearar-3
I _believe_ that this is my fault, for not finishing off what I'd started in  http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-February/168593.html. But life intervened.

frank

On Mon, 6 Jan 2020 at 13:57, Thiede, Christoph <[hidden email]> wrote:

Hi Eliot,


Can you give an exact step-by-step example to reproduce?

It appears that the context is reset before compiling the method, so when you have a syntax error, the execution will have been reset. However, I could not find a scenario in which the syntax error is displayed in the original text ...

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Montag, 6. Januar 2020 22:18:02
An: The general-purpose Squeak developers list
Betreff: [squeak-dev] tedious programming-in-the-debugger error needs fixing
 
Hi All,

    if in a block in the debugger and one redefines the method, the debugger says "I will need to go back to the method that defined this block" or some such. If there is a syntax error in the new code one is trying to compile then the original method is displayed, the syntax error is displayed in that original text, and one's edited text is lost.
_,,,^..^,,,_
best, Eliot



Reply | Threaded
Open this post in threaded view
|

Re: tedious programming-in-the-debugger error needs fixing

Christoph Thiede
Hi Eliot,

when you reported this issue, I was not able to reproduce it. About two
months later, your new Sista bytecode set has arrived in the Trunk. Today, I
encountered a very similar issue, could reproduce it, and trace it back to a
comparison issue of Context >> #method which was affected by the
introduction of CompiledBlock instances. Is it possible that you already
used Sista in your image when reporting this bug?

In case you were able to reproduce the bug: Can you confirm whether
Tools-ct.987 (inbox) fixes the issue for you? :-)

Best,
Christoph



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: tedious programming-in-the-debugger error needs fixing

Eliot Miranda-2
Hi Christoph,

    I didn't do my due dilligence in reviewing the changes.  I've just hit a problem.  When I accept as method in the debugger I get an MNU of stepToStatement.  MorphicDebugger needs to implement stepToStatement, or contents:notifying: needs not to send it.  Can you please fix ASAP?  Apologies!!

On Thu, Sep 3, 2020 at 5:50 AM Christoph Thiede <[hidden email]> wrote:
Hi Eliot,

when you reported this issue, I was not able to reproduce it. About two
months later, your new Sista bytecode set has arrived in the Trunk. Today, I
encountered a very similar issue, could reproduce it, and trace it back to a
comparison issue of Context >> #method which was affected by the
introduction of CompiledBlock instances. Is it possible that you already
used Sista in your image when reporting this bug?

In case you were able to reproduce the bug: Can you confirm whether
Tools-ct.987 (inbox) fixes the issue for you? :-)

Best,
Christoph



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html



--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: tedious programming-in-the-debugger error needs fixing

Christoph Thiede

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


Best,

Christoph


PS: #stepToStatement gets relevant with the BytecodeDebugger changeset I proposed somewhen earlier in this year. I still would appreciate any review of it! :-)


Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Donnerstag, 24. September 2020 21:42:37
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] tedious programming-in-the-debugger error needs fixing
 
Hi Christoph,

    I didn't do my due dilligence in reviewing the changes.  I've just hit a problem.  When I accept as method in the debugger I get an MNU of stepToStatement.  MorphicDebugger needs to implement stepToStatement, or contents:notifying: needs not to send it.  Can you please fix ASAP?  Apologies!!

On Thu, Sep 3, 2020 at 5:50 AM Christoph Thiede <[hidden email]> wrote:
Hi Eliot,

when you reported this issue, I was not able to reproduce it. About two
months later, your new Sista bytecode set has arrived in the Trunk. Today, I
encountered a very similar issue, could reproduce it, and trace it back to a
comparison issue of Context >> #method which was affected by the
introduction of CompiledBlock instances. Is it possible that you already
used Sista in your image when reporting this bug?

In case you were able to reproduce the bug: Can you confirm whether
Tools-ct.987 (inbox) fixes the issue for you? :-)

Best,
Christoph



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html



--
_,,,^..^,,,_
best, Eliot


Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: tedious programming-in-the-debugger error needs fixing

marcel.taeumel
Hi all.

Merged and fixed.

Best,
Marcel

Am 25.09.2020 16:58:40 schrieb Thiede, Christoph <[hidden email]>:

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


Best,

Christoph


PS: #stepToStatement gets relevant with the BytecodeDebugger changeset I proposed somewhen earlier in this year. I still would appreciate any review of it! :-)


Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Donnerstag, 24. September 2020 21:42:37
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] tedious programming-in-the-debugger error needs fixing
 
Hi Christoph,

    I didn't do my due dilligence in reviewing the changes.  I've just hit a problem.  When I accept as method in the debugger I get an MNU of stepToStatement.  MorphicDebugger needs to implement stepToStatement, or contents:notifying: needs not to send it.  Can you please fix ASAP?  Apologies!!

On Thu, Sep 3, 2020 at 5:50 AM Christoph Thiede <[hidden email]> wrote:
Hi Eliot,

when you reported this issue, I was not able to reproduce it. About two
months later, your new Sista bytecode set has arrived in the Trunk. Today, I
encountered a very similar issue, could reproduce it, and trace it back to a
comparison issue of Context >> #method which was affected by the
introduction of CompiledBlock instances. Is it possible that you already
used Sista in your image when reporting this bug?

In case you were able to reproduce the bug: Can you confirm whether
Tools-ct.987 (inbox) fixes the issue for you? :-)

Best,
Christoph



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html



--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: tedious programming-in-the-debugger error needs fixing

Eliot Miranda-2
In reply to this post by Christoph Thiede
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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.

Cheers!!

Best,

Christoph


PS: #stepToStatement gets relevant with the BytecodeDebugger changeset I proposed somewhen earlier in this year. I still would appreciate any review of it! :-)


Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Donnerstag, 24. September 2020 21:42:37
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] tedious programming-in-the-debugger error needs fixing
 
Hi Christoph,

    I didn't do my due dilligence in reviewing the changes.  I've just hit a problem.  When I accept as method in the debugger I get an MNU of stepToStatement.  MorphicDebugger needs to implement stepToStatement, or contents:notifying: needs not to send it.  Can you please fix ASAP?  Apologies!!

On Thu, Sep 3, 2020 at 5:50 AM Christoph Thiede <[hidden email]> wrote:
Hi Eliot,

when you reported this issue, I was not able to reproduce it. About two
months later, your new Sista bytecode set has arrived in the Trunk. Today, I
encountered a very similar issue, could reproduce it, and trace it back to a
comparison issue of Context >> #method which was affected by the
introduction of CompiledBlock instances. Is it possible that you already
used Sista in your image when reporting this bug?

In case you were able to reproduce the bug: Can you confirm whether
Tools-ct.987 (inbox) fixes the issue for you? :-)

Best,
Christoph



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html



--
_,,,^..^,,,_
best, Eliot



--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: tedious programming-in-the-debugger error needs fixing

Chris Muller-3
On Mon, Sep 28, 2020 at 10:07 AM Eliot Miranda <[hidden email]> wrote:
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Development methodology (was: tedious programming-in-the-debugger error needs fixing)

Christoph Thiede

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 <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
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 <[hidden email]> wrote:
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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


Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: tedious programming-in-the-debugger error needs fixing

marcel.taeumel
In reply to this post by Chris Muller-3
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 <[hidden email]>:

On Mon, Sep 28, 2020 at 10:07 AM Eliot Miranda <[hidden email]> wrote:
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: tedious programming-in-the-debugger error needs fixing

Karl Ramberg
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 <[hidden email]> 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 <[hidden email]>:

On Mon, Sep 28, 2020 at 10:07 AM Eliot Miranda <[hidden email]> wrote:
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: tedious programming-in-the-debugger error needs fixing

marcel.taeumel
Hi Karl.

I thought Trunk was for bleeding edge development. And that the bleeding occurs when stuff needs further fixing.

That shouldn't be an excuse for hastly committing poorly tested changes. ;-) It's a matter of discipline, thought, and sometimes to restrain oneself. Especially when people are not working on Squeak full-time but have to carefully allocate time slots, e.g., on weekends.

It can sometimes be a tricky balancing act.

Best,
Marcel

Am 29.09.2020 10:51:18 schrieb karl ramberg <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

On Mon, Sep 28, 2020 at 10:07 AM Eliot Miranda <[hidden email]> wrote:
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Development methodology

Herbert König
In reply to this post by Christoph Thiede

Hi all,


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.


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


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.


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.


Best regards,


Herbert



Am 29.09.20 um 01:38 schrieb Thiede, Christoph:

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 [hidden email] im Auftrag von Chris Muller [hidden email]
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 <[hidden email]> wrote:
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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


    


Reply | Threaded
Open this post in threaded view
|

Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)

marcel.taeumel
In reply to this post by Christoph Thiede
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 --- 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 --- 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 <[hidden email]>:

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 <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
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 <[hidden email]> wrote:
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Development methodology

Eliot Miranda-2
In reply to this post by Herbert König
Hi Herbert,

On Tue, Sep 29, 2020 at 5:44 AM Herbert <[hidden email]> wrote:

Hi all,


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.


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.

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.

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.

But instead of simply discarding the Newspeak build to get green tests again, better would be to 
a) not chain the builds so that an early failure prevents potentially successful subsequent builds, i.e. attempt to build everything
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"

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


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.


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.


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.

Best regards,


Herbert



Am 29.09.20 um 01:38 schrieb Thiede, Christoph:

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 [hidden email] im Auftrag von Chris Muller [hidden email]
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 <[hidden email]> wrote:
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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


    



--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Development methodology

Herbert König
Hi Eliot,

...snip...
 *BUT* (and it's a big BUT) only if the test signals can be seen.
...snip...

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

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.

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.


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.

But instead of simply discarding the Newspeak build to get green tests again, better would be to 
a) not chain the builds so that an early failure prevents potentially successful subsequent builds, i.e. attempt to build everything
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"

No, 'This specific build has failed' please. Even with a few builds you usually start looking at the wrong end. At least I do.

Cheers,

Herbert


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


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.


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.


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.

Best regards,


Herbert



Am 29.09.20 um 01:38 schrieb Thiede, Christoph:

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 [hidden email] im Auftrag von Chris Muller [hidden email]
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 <[hidden email]> wrote:
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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




--
_,,,^..^,,,_
best, Eliot


    



Reply | Threaded
Open this post in threaded view
|

Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)

Chris Muller-4
In reply to this post by Christoph Thiede
Hi Christoph,

(sorry for so much traffic from me today folks!)

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

I hear you, and I do think the video-game-fragathon-free-for-all style ;) might be... interesting to try out, IF there would not be permanent consequences from such an experiment in terms of our current Monticello implementation, which keeps the entire, ever-growing database of ancestry in RAM.  We currently can't afford to make "proposals" or have "dev discussions" there.  (Honestly, it seems like there's a good chance for that to be fixable -- some safe, backward-compatible way to trim the ancestry in memory -- but, TMK no attempts (other than MCInfoProxy) have so far been made at addressing it, but that's another discussion...).

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. 

An Inbox repository pane docked on a tab in your IDE could go a long way toward simulating the dynamism of such a workflow -- some hot buttons to merge, unmerge, Reparent any versions in the Inbox -- does it matter if it came that way vs. "Update Squeak"?.  It could help it feel a lot more integrated.

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

It sounds like you're burning time there friend.  ;)  All that's necessary is to base off _some_ version in trunk (it can be old).  When it's integrated, the integrator will (should!) use the "Reparent" button to sculpt the ancestry appropriately for the trunk (we need an ancestor selector on the commit dialog!)  And this does touch on one reason I'm skeptical of the active-commit git-style workflow -- the overhead.  When I'm spending my time writing version notes, committing and updating, I'm not writing code.  With everyone doing it, everyone must constantly merging everyone elses' active-committal style, and if they're not really tested ("eh, fix later!") then, at least in a live Smalltalk IDE with dependency on that code to your actual ability to work, -- as you encountered the other day with Tobias' commit -- it becomes worthy to scrutinize the "efficiency" of this methodology to ensure it's real and not only perceived.  Making a commit "feels" productive, but the extra efficiency from this methodology can only be realized when and if it's actually consumed by someone else and it was of good enough quality to boost their development.  But, our community is small, and busy.

By contrast, when I know its a steady-drip of quality commits, I have no qualms about clicking "Update Squeak".  I'm confident it'll be a positive click, and not a sideways or even risky click, because I know it's tested upgrades.

If you decide you're interested in addressing some of our IDE's limitations in conjunction with an explicit proposal for tweaking us toward more dynamism, I promise I'll at least be open-minded about it.  But, I may have some questions...  :/

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 <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
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 <[hidden email]> wrote:
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Development methodology

Eliot Miranda-2
In reply to this post by Herbert König
Hi Herbert,

    will toppist did brevity.  I agree with both of your responses below.

_,,,^..^,,,_ (phone)

On Sep 29, 2020, at 1:58 PM, Herbert König <[hidden email]> wrote:

 Hi Eliot,

...snip...
 *BUT* (and it's a big BUT) only if the test signals can be seen.
...snip...

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

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.

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.


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.

But instead of simply discarding the Newspeak build to get green tests again, better would be to 
a) not chain the builds so that an early failure prevents potentially successful subsequent builds, i.e. attempt to build everything
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"

No, 'This specific build has failed' please. Even with a few builds you usually start looking at the wrong end. At least I do.

Cheers,

Herbert


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


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.


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.


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.

Best regards,


Herbert



Am 29.09.20 um 01:38 schrieb Thiede, Christoph:

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 [hidden email] im Auftrag von Chris Muller [hidden email]
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 <[hidden email]> wrote:
Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <[hidden email]> 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




--
_,,,^..^,,,_
best, Eliot


    




Reply | Threaded
Open this post in threaded view
|

Re: Development methodology (was: tedious programming-in-the-debugger error needs fixing)

Christoph Thiede
In reply to this post by Chris Muller-4
Hi all,

thanks for this insightful discussion! :-)

> (sorry for so much traffic from me today folks!)

No need to worry, I'm glad about any message by you!

I will give a short case study and tell you how I think it probably could be
performed more efficiently using the GitHub workflow:

1) I'm proposing a new extension to some Squeak component, let's say a menu
for the HelpBrowser. To do this, I upload a new version to the inbox
(Package-ct.2 based on Package-xyz.1).
2) Some kind person is giving me some feedback on the proposal so I am
reworking it. To share the new version with the community, I have two
options: A. Upload a new inbox version (Package-ct.3) that depends on
Package-ct.2 or B. upload a new inbox version that contains a copy of all
changes of Package-ct.2, too, that is based on Package-xyz.1 again, and that
explains that Package-ct.2 can moved into the treated inbox now. Usually, I
choose option B because it makes it easier to read the complete diff of my
proposal compared to the trunk (but let's see step 3 for this decision). In
every case, I need to leave a note referring to Package-ct.2.
3) Some kind person would like to clean up the inbox, including reviewing
and eventually merging of my proposal, but where should they find all
relevant information? Regarding to Package-ct.2, the Monticello Browser does
not give you any hint that it is stale and should be moved into the treated
inbox (provided that I chose option B in step 2) because you cannot see the
discussion from the mailing list there. The mail-archive thread about
Package-ct.2, too, does not contain any reference to Package-ct.3 (unless
I'm sending another piece of noise manually). On the other hand, if I chose
option 2.A, you cannot review Package-ct.3 standalone neither in the
Monticello Browser nor in the mailing thread. And things get more
complicated if just another review is left on the proposal before it can be
merged ...
Of course, as I am not a merging person, I cannot tell whether step 3
exactly describes your workflow as a merger, but I am facing very similar
issues when trying to get an overview of my own contribution. And also, we
had several small incidents in the past when something was merged that
actually should have been improved before (just for example,
Regex-Core-ct.56).

So how could this look differently when applying the GitHub workflow?
1) For the initial proposal, I'm opening a new Pull Request to merge
"helpbrowser-menu" into "trunk" with a single commit commit-a.
2) To react on the kind person's feedback, I add another commit commit-b to
this branch. GitHub, the GitBrowser, and every other git client will
automatically display the connection between both commits, and because
commit-a is no longer a head commit, it will not be considered as a complete
feature by anybody any longer.
3) Every subsequent feedback can be left directly to the Pull Request thread
(which can be easily synchronized with the mailing list using a bot similar
to the OpenSmalltalk-VM-Bot) and be resolved by just another commit to this
branch. All version information is kept at one single place.
*) As a bonus, GitHub offers a bunch of useful features that make it easier
to overview and organize all contributions. For example, we can
automatically run the CI for every Pull Request (which I'm sure would help
us to introduce a smaller number of bugs into the Trunk/master); issue/PR
references are automatically displayed on both ends of a link; people can be
assigned to certain PRs; labels can be used to mark a PR as draft, fix,
enhancement, review, etc. and much more ... Also, there is already an
existing project to integrate GitHub conversations into Squeak, see
SqueakIssueIntegration.
*) Another plus could be organizing all packages in one repository to get
rid of changesets sent to the list which I find truly unhandy as they are
not really designed for versioning.

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

I agree that we will need to keep some policies, e.g. "checkout a change and
test it before merging" it, but unless this policy is violated, I do not see
how the quality should be impaired.
But won't you agree that reviewing stuff gets easier if you only have to
check one location instead of two or three, and requesting changes does not
require to start the next from the beginning again?

> Just look at the OpenSmalltalk VM repo:
> https://github.com/OpenSmalltalk/opensmalltalk-vm --- Many open issues and
> pull requests, some of them are several years old.

Hm, given a total of 335 PRs, 12 open PRs is not such a bad number, that is
about 3.6% of all contributions. The percentage of open inbox commits
733/(733+12744) is 5.4% which is somewhat worse, and this does not even
include all the unmerged changesets from the mailing list ... :-)

> When I'm spending my time writing version notes, committing and updating,
> I'm not writing code.

I cannot follow you at this point. Whether you upload a version to the inbox
or create a GH PR, you have to document your changes to some extent either
way. The difference is that if you make a follow-up commit to an existing
PR, you can be very brief (e.g. "fix a typo") and squash your commits when
merging the PR.

> With everyone doing it, everyone must constantly merging everyone elses'
> active-committal style, and if they're not really tested ("eh, fix
> later!") then

> Making a commit "feels" productive, but the extra efficiency from this
> methodology can only be realized when and if it's actually consumed by
> someone else and it was of good enough quality to boost their development.

There is no need to lower code quality just because of using a branching
concept, is it? CI can help us to *improve* quality but does not force us to
merge more often. Just in the opposite, it would be possible to develop
against an extra stable branch as proposed by Herbert (unless too many
people are touching the same components at the same time). And also, git has
a feature called rebase, so there is no need for too many merge commits :-)

> we need an ancestor selector on the commit dialog!

+1

> But, our community is small

That's another good point, I'd love to see more contributions by more people
on the Squeak project! But from my point of view, the mailing-list-based
workflow is simply a quite conservative approach that might keep many
potentially interested casual Squeakers away from participating in our
community. I think the following article provides a very good summary of my
thought on this matter: "Relying on plain-text email is a 'barrier to entry'
for kernel development, says Linux Foundation board member"
(https://www.theregister.com/2020/08/25/linux_kernel_email/). Marcel argued
that the mailing list works as a filter for keeping unexperienced or
unqualified people away from our community, but I believe our community is
too small for throwing away all these possible contributions.

Best,
Christoph



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Carpe Squeak!
123