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.
>
   https://en.wikipedia.org/wiki/Capability_Maturity_Model#Maturity_models



>
>
> 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>
> 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/afa33bd7/attachment.html>