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

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

http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com 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 <christoph.thiede@student.hpi.uni-potsdam.demailto:christoph.thiede@student.hpi.uni-potsdam.de> 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

Hi Christoph,

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

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

http://www.hpi.de/

*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com *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 < christoph.thiede@student.hpi.uni-potsdam.de> 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

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@lists.squeakfoundation.org im Auftrag von Chris Muller asqueaker@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@gmail.commailto:eliot.miranda@gmail.com> wrote: Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@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

Hi Herbert,

On Tue, Sep 29, 2020 at 5:44 AM Herbert herbertkoenig@gmx.net 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 squeak-dev-bounces@lists.squeakfoundation.org squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Chris Muller asqueaker@gmail.com asqueaker@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@gmail.com wrote:

...

Hi Christoph,

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

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 herbertkoenig@gmx.net 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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Chris Muller asqueaker@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@gmail.com wrote:

...

Hi Christoph,

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

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

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@lists.squeakfoundation.org im Auftrag von Chris Muller asqueaker@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@gmail.com wrote:

...

Hi Christoph,

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

Sounds like Christoph wants an issue tracker that is integrated with the version control system. GitHub just happens to be one of the platforms to offer this (next to Bitbucket, and Gitlab, and Jira, and what not).

If I remember correctly, that is one of the reasons why Pharo has moved to Git and GitHub: because they did not want to reinvent/reimplement these tools.

There already is https://github.com/squeak-smalltalk/ and the squeak-app repository over there (through Travis CI) is what sends us the smalltalkCI reports for Trunk. Maybe we could use another repository there as an issue tracker and subscribe issue/pull request comments to squeak-dev in the same manner as the CI. (I don't suppose that the Mantis is still frequently used or would send email to the list, correct?) Now since Squeak does not switch to Git (given the feelings of several prominent people here towards Git), what remains to be solved is the integration with the version control system.

Maybe we have to build the proper Monticello frontend to Git repositories after all... despite enjoying the non-Monticello tools such as the Git Browser in and around HPI. I don't suppose anyone will be able to go the other way around and write, maintain, and operate the custom Monticello issue tracker platform in their free time.

Kind regards, Jakob

Christoph Thiede wrote

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.

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

Am Do., 1. Okt. 2020 um 23:43 Uhr schrieb Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de:

...

Sounds like Christoph wants an issue tracker that is integrated with the version control system.

Exactly. You managed to summarize in one sentence which took me two screen pages. :-)

Usually it's me who writes the walls of text, but you're welcome. ;-)

The actual question is how big is the actual demand for such a hybrid/two-way VCS for us a community (and not for me as a single Monticello-moaning person) and how many people actually would like to use the git interface.

Well I have lost track myself of how many of my Inbox submissions have actually been merged, or even been commented or not... even with a label for them in Gmail I find it just too cumbersome to follow up and run after all of those that get no attention (and compared to you I don't submit all that many). The Inbox submission email can be far away from the Trunk merge email of the same version, just to give one example of another first world problem. Also most inbox threads do not explicitly get "closed" and instead remain dangling around.

On 2020-10-01, at 3:13 PM, Jakob Reschke forums.jakob@resfarm.de wrote: Also subscribing to a mailing list feels somehow different than signing up on Stack Overflow or GitHub.

I think this must be something of a generational thing. Us Old Folk are, I suspect, much more likely to see it the other way round. A lot of us have lived on email for... well, about as long as humans have known about electricity. Signing up on a website, on the other hand, seems really annoying and intrusive to me.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SEXI: Sign EXtend Integer

Hi Christoph and Jakob,

Now since Squeak does not switch to Git (given the feelings of several

prominent people here towards Git)

Hmm, that doesn't sound quite right. What I sense are such (positive) "feelings" TOWARDS Git in some members, it has them wanting to use *that particular tool* (vs. other tools or solutions which could also address the community's needs, i.e., see below). I sometimes think "the tool" and the associated "popularity" is the end-goal in and of itself, rather than the output artifact. Please pardon me if I'm mistaken about that. For me, it's not really anything about any "feelings" about Git as the (im)practicality of integration. It's a beast. To bring a beast into _everyone's_ workflow that has 90% more "stuff" than we need, and requires them to sign up just to use -- I think it would be a "filter" on the community, especially of non-developers (hint: You and Jakob are developers). For me, being hosted by a private company is not so attractive.

I do think some of these issues you describe with the Inbox contribution process are shallow enough they could be largely mitigated with simple upgrades to our existing tools. For example, you could submit an improvement that allows original contributors of Inbox items to move them to Treated themself. You could add a button to filter out all entries in the Inbox which have further descendants also in the Inbox. You could make an, "update from Inbox" which would only download packages for which have your loaded versions as ancestors. There are many simple things that could be done. A bug-tracker is a bigger deal, but it's often a lot less overhead to just FIX the bug than open, track, and close a bug report. We do have Mantis to keep track of the longer-term bugs.

But, again, this is "not Git", which seems to be the desired "feature". :/

We have *decades* of Monticello packages for Squeak across not just our own repositories, but many other "external" legacy repositories. (i.e., see the "repositories" category of Installer class side). Obviously, our tools and methodology will be an on-going discussion, but I don't see this legacy ever going away completely, no matter what we do, Monticello will continue to be used by some. It seems clear that the only path to Git and other tools is a backward-compatible integration with existing tools, a "stepping stone" that doesn't require a major adjustment like losing method-level timestamp information. But it's not going to write itself. Only the burning interest within people like you and/or Jakob will get it done. :)

- Chris

On Sun, Oct 4, 2020 at 5:39 PM Douglas Brebner kirtai+st@gmail.com wrote:

On 04/10/2020 21:36, Chris Muller wrote:

...

For me, being hosted by a private company is not so attractive.

Are you confusing git with Github here? There are many git hosters and you can host it yourself.

Github issues are not based on git, it's a proprietary solution exclusive to github.

Hi Jakob,

On Oct 4, 2020, at 6:14 PM, Jakob Reschke forums.jakob@resfarm.de wrote:

Hi Chris,

I suppose many of us drawn towards Git instead of Monticello find Monticello lacking in not only minor ways. The alternative or improvement needs not necessarily be Git, but given its acceptance in the wider developer community, it is an obvious choice.

Chris Muller-3 wrote

...

For me, it's not really anything about any "feelings" about Git as the (im)practicality of integration. It's a beast. To bring a beast into _everyone's_ workflow that has 90% more "stuff" than we need [...]

What exactly do you think is so massive about Git? The basics are really quite simple. The complexity comes with the vast number of possibilities to transform a graph of history, and canonical Git supporting many of them, but you do not have to do or support all of these. Other idiosyncrasies of Git can be simply omitted. For example, you will not find anything about the "index" or staging area of Git in the Git Browser tools. Git vocabulary is different from Monticello vocabulary (that is true for almost all pairs of version control systems) and Git has some different ideas of how tracking works and what to put in a single repository. But if you stick to the Monticello workflows and know the corresponding Git vocabulary, I contend that Git is not more complicated than Monticello. Fixing a Monticello ancestry is at least as complicated as doing a rebase ("advanced feature") in Git; after you have learned either, you can confidently wield either.

In other ways, Monticello just looks simpler because something is in fact missing. Consider branches: most Git tools have knobs to deal with them in various ways, while Monticello tools just deny to talk about branches. Monticello ancestry does support branching, yet I think Monticello lacks first-class objects for branches, with all the implications for repository handling. The tools might look simpler without branch management, but it is not a feature but rather the lack of one. Note that you can also avoid branch management in Git: just stay on the mainline branch forever and merge your commits back and forth with the upstream repository's mainline. While it might appear simpler that way, you might as well call it less organized.

Monticello supports branches. And merging between them is as easy as merging any other version of a package. And Monticello does support recording histories across branches.

The two things that Monticello has over git are - that it is used without leaving the image. I’ve yet to see a git integration where at some stage one was forced to try and fix things in git, or that the image and the git repository got out of sync, or that if one tried to use more than one image against a git repository something horrible broke - that it can be extended using our own tools. Git is written in C and controlled by a separate community. One gives up great autonomy when allowing ones core VCS to be in a foreign system. When git crashes it crashes. It doesn’t raise a friendly debugger in which one can determine and fix and proceed from the bug, it segfaults, in optimized code, and you’re hosed.

Personally I don’t want to work in that kind of world. The Pharo crowd do. I will do everything in my power to prevent Squeak going the same way. And if I’m unsuccessful I’ll go somewhere else.

Chris Muller-3 wrote

...

[...] requires them to sign up just to use -- I think it would be a "filter" on the community, especially of non-developers (hint: You and Jakob are developers). For me, being hosted by a private company is not so attractive.

As Phil pointed out, you seem to confuse Git with GitHub here. But your arguments are applicable if we take the integrated issue tracker into account because that needs to be run by someone. In theory Squeak could host an own GitLab Community Edition server instead of relying on GitHub.

Note that you also have to sign up to use Mantis or participate on the mailing list or the Slack channel.

About the "filter": how many non-developers try to trace inbox contributions or engage in code reviews? How many non-developers use Monticello (given that it can only track packages and configuations thereof)? The "filter" might not take anything interesting away from the other target audiences after all.

We do not wish to move all discussions from the list to pull requests. Also the idea was to link up pull request conversations with the list, like the CI job reports, or conversations on the OpenSmalltalk-VM repository to the vm-dev list.

Chris Muller-3 wrote

...

For example, you could submit an improvement that allows original contributors of Inbox items to move them to Treated themself.

How? Only Trunk committers have access to the Squeaksource treating backend, so neither the code nor the tool is available to normal users for improvement. Guest users cannot even delete versions from the inbox repository, can they?

Chris Muller-3 wrote

...

You could add a button to filter out all entries in the Inbox which have further descendants also in the Inbox. You could make an, "update from Inbox" which would only download packages for which have your loaded versions as ancestors.

I don't understand how these would help in the tracking of issues, can you elaborate please? My understanding: The first shows you the tips of all loose branches in the inbox, but still without a mapping to issues (which is not necessarily a 1:1 mapping, with reinforced complexity because of the drive towards a compact ancestry...). Combined with some client-side extensions it might allow us to track branches locally, but not share them explicitly. To find remote branches, you would have to download many of these versions first because only then you can access their ancestry (you don't know in advance which versions are the tips, and combined with the redundancy among versions, this is a Monticello implementation flaw). The second would allow an update if someone moved some of your own branches forward. But it rarely happens nowadays.

Chris Muller-3 wrote

...

There are many simple things that could be done. A bug-tracker is a bigger deal, but it's often a lot less overhead to just FIX the bug than open, track, and close a bug report. We do have Mantis to keep track of the longer-term bugs.

I think this plays down the issue. It being a bigger deal is exactly why we would like to use an existing platform. "Just FIX the bug" is not always so straightforward that a single new version is sufficient. There might be multiple iterations, or multiple packages affected, or many versions towards a larger goal over an extended period of time. That's why we would like some integrated issue tracking, even for short-term bugs. Think more of pull requests with conversation and review facilities than of bug tickets. Pull requests, combined with a system that can actually track branches or tasks, allow for iterative refinement and feedback while binding all the iterations or steps together.

Mantis is not integrated with Monticello, is it? Also it doesn't look very active.

Chris Muller-3 wrote

...

We have *decades* of Monticello packages for Squeak across not just our own repositories, but many other "external" legacy repositories. [...] Monticello will continue to be used by some.

In my opinion this is no argument against different tools because nobody suggested to remove Monticello from Squeak. As we already see in practice, Git tools and Monticello tools, as well as both kinds of repositories, can co-exist.

Otherwise we could still use floppy disks because there are decades of software packages that were distributed on floppy disks, yet we don't. :-)

Chris Muller-3 wrote

...

It seems clear that the only path to Git and other tools is a backward-compatible integration with existing tools

Well, other paths have already been walked. ;-) But in which direction goes this backwards- compatibility? Do you want be able to use newer tools also on old repositories? Alright, that would be nice. Do you want to be able to use newer repositories in old tools? Why, given that it will probably restrict the newer repositories?

Chris Muller-3 wrote

...

a "stepping stone" that doesn't require a major adjustment like losing method-level timestamp information.

This seems to confound the use of Git with the use of the Tonel format with a Pharo-style implementation.

Otherwise it affirms what I wrote a few messages before: maybe we do have to bite the bullet and write a proper MCGitRepository that molds Git-hosted projects into the Monticello tools, even though we have already created other tools.

By the way, the draft spec of Tonel that Martin was offering to the list in a recent thread demands that custom attributes on classes, methods, ... be preserved by the system. So even if Squeak woulde use Tonel more often in the future, it would not necessarily mean that method timestamps have to be sacrificed. Squot and its Git tools are stored in the FileTree format, have been Git-hosted from the start, include some packages whose Monticello ancestries have been converted and integrated into the Git history, and has method timestamps all over.

Chris Muller-3 wrote

...

But it's not going to write itself. Only the burning interest within people like you and/or Jakob will get it done. :)

Thank you for the encouragement. Unfortunately with regards to Monticello tools it recurrently sounds like: "If you want contemporary features, you must add them to the old tools because we do not want to adopt new tools that can already do the job." Forgive me if this reads too polemic.

Kind regards, Jakob

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

Brainstorming here, laugh, mock, fume, etc as appropriate

An enterprising dev implements the git server in squeak ....

1. any git client interacts just as with the c git. 2. Behind the scenes, git uuid's are used but so are monticello "stuff" 3. Monticello interacts with the sqGit server seamlessly.( Handoff?) 4. Bug happens...native squeak tools...

I have learned and forgotten Git at least twice,but iirc, it is a tree of uuids and ops on that tree. If that is true, I sense an opportunity for a dev who is interested

If i had time, I would do it as it sounds like a fun project. I do not have time. ):

---- On Mon, 05 Oct 2020 02:50:36 -0400 eliot.miranda@gmail.com wrote ----

Hi Jakob,

On Oct 4, 2020, at 6:14 PM, Jakob Reschke forums.jakob@resfarm.de wrote:

Hi Chris,

I suppose many of us drawn towards Git instead of Monticello find Monticello lacking in not only minor ways. The alternative or improvement needs not necessarily be Git, but given its acceptance in the wider developer community, it is an obvious choice.

Chris Muller-3 wrote

...

For me, it's not really anything about any "feelings" about Git as the (im)practicality of integration. It's a beast. To bring a beast into _everyone's_ workflow that has 90% more "stuff" than we need [...]

What exactly do you think is so massive about Git? The basics are really quite simple. The complexity comes with the vast number of possibilities to transform a graph of history, and canonical Git supporting many of them, but you do not have to do or support all of these. Other idiosyncrasies of Git can be simply omitted. For example, you will not find anything about the "index" or staging area of Git in the Git Browser tools. Git vocabulary is different from Monticello vocabulary (that is true for almost all pairs of version control systems) and Git has some different ideas of how tracking works and what to put in a single repository. But if you stick to the Monticello workflows and know the corresponding Git vocabulary, I contend that Git is not more complicated than Monticello. Fixing a Monticello ancestry is at least as complicated as doing a rebase ("advanced feature") in Git; after you have learned either, you can confidently wield either.

In other ways, Monticello just looks simpler because something is in fact missing. Consider branches: most Git tools have knobs to deal with them in various ways, while Monticello tools just deny to talk about branches. Monticello ancestry does support branching, yet I think Monticello lacks first-class objects for branches, with all the implications for repository handling. The tools might look simpler without branch management, but it is not a feature but rather the lack of one. Note that you can also avoid branch management in Git: just stay on the mainline branch forever and merge your commits back and forth with the upstream repository's mainline. While it might appear simpler that way, you might as well call it less organized.

Monticello supports branches. And merging between them is as easy as merging any other version of a package. And Monticello does support recording histories across branches.

The two things that Monticello has over git are - that it is used without leaving the image. I’ve yet to see a git integration where at some stage one was forced to try and fix things in git, or that the image and the git repository got out of sync, or that if one tried to use more than one image against a git repository something horrible broke - that it can be extended using our own tools. Git is written in C and controlled by a separate community. One gives up great autonomy when allowing ones core VCS to be in a foreign system. When git crashes it crashes. It doesn’t raise a friendly debugger in which one can determine and fix and proceed from the bug, it segfaults, in optimized code, and you’re hosed.

Personally I don’t want to work in that kind of world. The Pharo crowd do. I will do everything in my power to prevent Squeak going the same way. And if I’m unsuccessful I’ll go somewhere else.

Chris Muller-3 wrote

...

[...] requires them to sign up just to use -- I think it would be a "filter" on the community, especially of non-developers (hint: You and Jakob are developers). For me, being hosted by a private company is not so attractive.

As Phil pointed out, you seem to confuse Git with GitHub here. But your arguments are applicable if we take the integrated issue tracker into account because that needs to be run by someone. In theory Squeak could host an own GitLab Community Edition server instead of relying on GitHub.

Note that you also have to sign up to use Mantis or participate on the mailing list or the Slack channel.

About the "filter": how many non-developers try to trace inbox contributions or engage in code reviews? How many non-developers use Monticello (given that it can only track packages and configuations thereof)? The "filter" might not take anything interesting away from the other target audiences after all.

We do not wish to move all discussions from the list to pull requests. Also the idea was to link up pull request conversations with the list, like the CI job reports, or conversations on the OpenSmalltalk-VM repository to the vm-dev list.

Chris Muller-3 wrote

...

For example, you could submit an improvement that allows original contributors of Inbox items to move them to Treated themself.

How? Only Trunk committers have access to the Squeaksource treating backend, so neither the code nor the tool is available to normal users for improvement. Guest users cannot even delete versions from the inbox repository, can they?

Chris Muller-3 wrote

...

You could add a button to filter out all entries in the Inbox which have further descendants also in the Inbox. You could make an, "update from Inbox" which would only download packages for which have your loaded versions as ancestors.

I don't understand how these would help in the tracking of issues, can you elaborate please? My understanding: The first shows you the tips of all loose branches in the inbox, but still without a mapping to issues (which is not necessarily a 1:1 mapping, with reinforced complexity because of the drive towards a compact ancestry...). Combined with some client-side extensions it might allow us to track branches locally, but not share them explicitly. To find remote branches, you would have to download many of these versions first because only then you can access their ancestry (you don't know in advance which versions are the tips, and combined with the redundancy among versions, this is a Monticello implementation flaw). The second would allow an update if someone moved some of your own branches forward. But it rarely happens nowadays.

Chris Muller-3 wrote

...

There are many simple things that could be done. A bug-tracker is a bigger deal, but it's often a lot less overhead to just FIX the bug than open, track, and close a bug report. We do have Mantis to keep track of the longer-term bugs.

I think this plays down the issue. It being a bigger deal is exactly why we would like to use an existing platform. "Just FIX the bug" is not always so straightforward that a single new version is sufficient. There might be multiple iterations, or multiple packages affected, or many versions towards a larger goal over an extended period of time. That's why we would like some integrated issue tracking, even for short-term bugs. Think more of pull requests with conversation and review facilities than of bug tickets. Pull requests, combined with a system that can actually track branches or tasks, allow for iterative refinement and feedback while binding all the iterations or steps together.

Mantis is not integrated with Monticello, is it? Also it doesn't look very active.

Chris Muller-3 wrote

...

We have *decades* of Monticello packages for Squeak across not just our own repositories, but many other "external" legacy repositories. [...] Monticello will continue to be used by some.

In my opinion this is no argument against different tools because nobody suggested to remove Monticello from Squeak. As we already see in practice, Git tools and Monticello tools, as well as both kinds of repositories, can co-exist.

Otherwise we could still use floppy disks because there are decades of software packages that were distributed on floppy disks, yet we don't. :-)

Chris Muller-3 wrote

...

It seems clear that the only path to Git and other tools is a backward-compatible integration with existing tools

Well, other paths have already been walked. ;-) But in which direction goes this backwards- compatibility? Do you want be able to use newer tools also on old repositories? Alright, that would be nice. Do you want to be able to use newer repositories in old tools? Why, given that it will probably restrict the newer repositories?

Chris Muller-3 wrote

...

a "stepping stone" that doesn't require a major adjustment like losing method-level timestamp information.

This seems to confound the use of Git with the use of the Tonel format with a Pharo-style implementation.

Otherwise it affirms what I wrote a few messages before: maybe we do have to bite the bullet and write a proper MCGitRepository that molds Git-hosted projects into the Monticello tools, even though we have already created other tools.

By the way, the draft spec of Tonel that Martin was offering to the list in a recent thread demands that custom attributes on classes, methods, ... be preserved by the system. So even if Squeak woulde use Tonel more often in the future, it would not necessarily mean that method timestamps have to be sacrificed. Squot and its Git tools are stored in the FileTree format, have been Git-hosted from the start, include some packages whose Monticello ancestries have been converted and integrated into the Git history, and has method timestamps all over.

Chris Muller-3 wrote

...

But it's not going to write itself. Only the burning interest within people like you and/or Jakob will get it done. :)

Thank you for the encouragement. Unfortunately with regards to Monticello tools it recurrently sounds like: "If you want contemporary features, you must add them to the old tools because we do not want to adopt new tools that can already do the job." Forgive me if this reads too polemic.

Kind regards, Jakob

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

Hi Jakob,

On Mon, Oct 5, 2020 at 12:18 PM Jakob Reschke forums.jakob@resfarm.de wrote:

Squeak - Dev mailing list wrote

...

An enterprising dev implements the git server in squeak ....

Sigh, if it were really necessary to satisfy the community... One could start from the FileSystem-Git package that ships with Squot and the Git Browser. At the heart Git is just a key-value (or rather sha1-to-object) store that contains blobs, trees, commits, and tags, plus a another key-value (string-to-string/sha1) store for the refs, so the server would even be free to choose how to persist the data.

Still, I think there are enough Git servers and implementations out there already. We should not write our own.

If we had the time to write a Git platform, we could instead write that integrated issue tracking platform for Monticello. The problem is already solved for Git.

Squeak - Dev mailing list wrote

...

1. any git client interacts just as with the c git.
2. Behind the scenes, git uuid's are used but so are monticello "stuff"

SHA-1 hashes, not UUIDs in Git, but yeah you could put anything behind the scenes as long as you can satisfy the interface.

Squeak - Dev mailing list wrote

...

3. Monticello interacts with the sqGit server seamlessly.( Handoff?)

So either we have that true Git adapter for Monticello (then we would also not need our own server implementation), or the server has a Monticello frontend in front of the Git backend.

If you were architecting this on a tight budget, which would you choose and why? If you were architecting this with an unlimited budget, what would you choose and why?

Squeak - Dev mailing list wrote

...

4. Bug happens...native squeak tools...

Unless the bug is on the server. Then hidden native Squeak tools and broken connection...

Right. But we suffer that with Monticello too. However, Git, like Monticello, has the advantage that one can work locally without uploading, unlike, say, Subversion, which (IIRC) can only do remote commits.

Squeak - Dev mailing list wrote

...

If i had time, I would do it as it sounds like a fun project. I do not have time. ):

Oh if only I had too much time...

Amen. But there is a corollary I can attest to. I've been able to work on Cog since 2008, 12 years already. That's as long as I worked on VisualWorks, and there's no sign that I'll have to stop working on opensmalltak-vm (Cog), Squeak or Terf any time soon. I had the architectural idea for Sista back in 2003, and had to ait for Clément's arrival to see it realised. This is to say that it is really important not to allow your ambition to be limited by your perceptio of how much time you have. Likely, if you're committed and passionate and lucky, you will have much more time than you imagine. Patience *is* a virtue, along with stubborn doggedness.

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

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

My opinion for what it us worth.

I prefer the monticelloand I agree it should be kept as the core squeak repo for reasons Eliot has given; its very similar to the Slackware tgz ways of doing things. Easy peasy, consistent and routine*

I see Jakob's git tool as a means to establish two way communication with the gitster userbase. The Roassal attempt uses it to get from git into squeak and then, hopefully into monticello for ease if installation. Call this the git-pull.

Regarding the git-push from squeak to git, Eliot mentioned a git centric use-case recently that he noted was very convenient. Let me thow in my initial thioughts for squeakbooks.irg/doc/seasideDoc...each book will live in sqyeak as a class; its content can be built internally in squeak via a workspace, helpbrowser, (what are those old fangled books in the flaps? Can it handle that?). From squeak, we can commit to github and monticelli, keeping monticello the spine if the project. From the outreach perspective, some git-heads will prefer to clone, checkout, edit and commit entirely from Emacs**

Count me in the keep monticello camp, and also count me in the outreach/facilitate camp.

Frankly, I do not like git. I have learned it twice and forgotten it twice, now I am on relearn three for the Roassal effort.

Cordially,

*Slackware is a very conservative linux distro, their community has solved the "next cool thing" itch with Slackbuilds.org. Core Slackware stays lean and old school while Slackbuilds has the cutting edge stuff. A cool featyre of that site is that each package lists its dependencies as links to the required package . For example, here us Rasterman's ground breaking E16 wirh ine dependency

https://slackbuilds.org/repository/14.2/desktop/e16/

While this one https://slackbuilds.org/repository/14.2/ham/wsjtx/ has 3 deps and the first dep has its deps...I find this model far easier to use than Metacello. Slackbuoilds is tarballs all the way down. Squeakbuilds can/ should be .mcz's all the way down abd That! Is Monticello, baby. Nite too that the drop down filters by version. The latest BabyIDE stuff would be solved with that. Couple that, with squeak-launcher that makes it easy to launch different squeak images wuth different VM's and you got yourself a user friendly sysrem.

**cue Tim screaming....

---- On Tue, 06 Oct 2020 06:47:58 -0400 christoph.thiede@student.hpi.uni-potsdam.de wrote ----

Hi all,

looks like I'm a bit late back to this debate again, but it's very nice it is still going on! There are many arguments I wanted to tell but Jakob already explained all of them better than I could do. So just let me come back to some points:

Mantis:

I just took another look at bugs.squeak.org again, and I'm sorry but I still think that our community deserves a better bug tracking solution than this. It really looks old-fashioned and, from today's point of view, quite chaotic and confusing. And compared to something like GitHub, it does not give me an idea of how to report a bug. Do I have to log in? Which credentials do I need to use? Why is there no register button anywhere? Also, there must be some reason why the latest issue was submitted nearly two years ago. Is Mantis connected to the mailing list at all? Asking all of you who have used Mantis in past and reported newer bugs to the mailing list instead, why did you do that? I would guess because mails provid higher visibility and interactivity, is this correct?

Phil, you called GitHub & Co. one trend of many that's durability is uncertain (correct me if I misunderstood you). I see this point, but looking at the current numbers I strongly believe that GitHub has reached a critical mass of developers and projects that won't move so quickly again. How many large global players have decided to use GitHub, including competitors of Microsoft itself such as Google, Apple, Facebook, etc.?

At least, according to the trends GitHub is way more popular than SourceForge, for example, has ever been, actually, it has even overtaken git itself on Google Trends: https://trends.google.com/trends/explore?date=all&q=github,sourceforge,g...

(By the way, if you search any old threads you can also find it on web.archive.org in most cases).

Here you're showing you've already fallen behind: the github trend for discussing things is already fading and those trendier than you have already moved on to the next thing: Slack is where it's at! In a year or two it will be something else... and the treadmill keeps going but not really going anywhere.

Slack is a group messenger used for communication in small to medium teams, but I can hardly imagine someone seriously uses this as a bug tracker for a large-scale software project with a big community, there is just too much noise when pressing Enter sends a new message. The same goes for social media platforms such as Google Plus that do not even offer basic tracking features such as closing or labeling. I don't think you can compare this.

Monticello ancestry does support branching, yet I think Monticello lacks first-class objects for branches, with all the implications for repository handling.

+1. And I feel the lack of branches for about every second or third submission I make to the inbox and am forced to reinvent my one pseudo branch wheel.

Git vs. GitHub vs. GitLab:

As Jakob already mentioned, they're not the same. I believe that GitHub offers the largest range by far, but personally I would still consider it as an improvement to set up a self-hosted GitLab instance (actually, from a technical point of view, I think GitLab offers even more convenience features for free).

But still, it's right what Eliot said about git and companies:

One gives up great autonomy when allowing ones core VCS to be in a foreign system

So why do you use git & GitHub for OpenSmalltalk-VM and not something like Monticello?

Which leads me to my most important point which Uncle Bob from Jakob's linked talk above gives this striking name to: elitism. In plain theory, I would consider it as an ideal, too, to have a Smalltalk system in which you can literally control every bit (ultimately, this might be a Smalltalk computer with no separate host system, where all drivers etc. are written in Smalltalk - completely neglecting every question of optimization). But in reality, the Squeak community, or even the entire Smalltalk community, is a quite small community, and I would love to change this and make Squeak/Smalltalk competitive again for contemporary development tasks, which involves the mutual boosting between tools/frameworks and developers. And because we are quite small at this point, we have two alternative ways we could go: Either we can spend our time on reimplementing every good and relevant idea from the "real world" in Squeak and making ourself even more comfortable in our small niche (which is, as I'm convinced, already very comfortable in many terms, compared to most other languages and environments); or we can join our forces and focus for now on opening our system towards the real world, both in terms of solutions and people. Which one would you choose?

Yet in my opinion Squeak really needs to get along with the outside world for the mutual benefit; we cannot afford to always reimplement everything in Smalltalk just to be able to comfortably debug the issues we wouldn't have if we had used something mature.

+1000

Best, Christoph

PS: And as a matter of course, I'm neither in the position nor willing to enforce any innovations that would deter some of our important community members from the Squeak Project. But I'm not giving up the hope that this discussion may reveal some more interesting insights about the desires and demands of us as a community. :-)

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

Phil B wrote

I do very much doubt the durability of github issues, especially given github's corporate ownership.

I think we should focus more on pull requests, not bug reports, and quick wins, even if temporary.

If pull requests were no longer free on GitHub (which would mean to cut away the prime feature around which that platform originally revolved), so be it. We could then still push the code somewhere else and return to another tool or process.

The benefit of using GitHub would be to get an improvement in contribution tracking *now* (or, rather quickly) without the investment of setting up a custom GitLab and spending the money on additional hosting resources if necessary, or developing a custom Monticello solution.

Phil B wrote

There have been numerous times in the past when 'everyone' (esp. major companies) flocked to things because they had achieved critical mass and weren't ever going to go away. Visual Basic and Java come to mind.

Java is very much alive in the enterprise and still looks like it isn't ever going to go away. Unfortunately, C isn't going away either. ;-)

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

Hi Christoph,

in this reply I’m only going to address the question about using GitHub for OpenSmalltalk-VM (for focus, see below).

On Oct 6, 2020, at 3:48 AM, Christoph Thiede <

christoph.thiede@student.hpi.uni-potsdam.de> wrote:

Hi all,

looks like I'm a bit late back to this debate again, but it's very nice it is still going on! There are many arguments I wanted to tell but Jakob already explained all of them better than I could do. So just let me come back to some points:

Mantis:

I just took another look at bugs.squeak.org again, and I'm sorry but I

still

think that our community deserves a better bug tracking solution than

this.

It really looks old-fashioned and, from today's point of view, quite

chaotic

and confusing. And compared to something like GitHub, it does not give me

an

idea of how to report a bug. Do I have to log in? Which credentials do I need to use? Why is there no register button anywhere? Also, there must be some reason why the latest issue was submitted nearly two years ago. Is Mantis connected to the mailing list at all? Asking all

of

you who have used Mantis in past and reported newer bugs to the mailing

list

instead, why did you do that? I would guess because mails provid higher visibility and interactivity, is this correct?

Phil, you called GitHub & Co. one trend of many that's durability is uncertain (correct me if I misunderstood you). I see this point, but

looking

at the current numbers I strongly believe that GitHub has reached a

critical

mass of developers and projects that won't move so quickly again. How many large global players have decided to use GitHub, including competitors of Microsoft itself such as Google, Apple, Facebook, etc.?

At least, according to the trends GitHub is way more popular than SourceForge, for example, has ever been, actually, it has even overtaken

git

itself on Google Trends:

https://trends.google.com/trends/explore?date=all&q=github,sourceforge,g...

(By the way, if you search any old threads you can also find it on web.archive.org in most cases).

...

Here you're showing you've already fallen behind: the github trend for discussing things is already fading and those trendier than you have already moved on to the next thing: Slack is where it's at! In a year

or

...

two it will be something else... and the treadmill keeps going but not really going anywhere.

Slack is a group messenger used for communication in small to medium

teams,

but I can hardly imagine someone seriously uses this as a bug tracker for

a

large-scale software project with a big community, there is just too much noise when pressing Enter sends a new message. The same goes for social media platforms such as Google Plus that do not even offer basic tracking features such as closing or labeling. I don't think you can compare this.

...

Monticello ancestry does support branching, yet I think Monticello lacks first-class objects for branches, with all the implications for

repository

...

handling.

+1. And I feel the lack of branches for about every second or third submission I make to the inbox and am forced to reinvent my one pseudo branch wheel.

Git vs. GitHub vs. GitLab:

As Jakob already mentioned, they're not the same. I believe that GitHub offers the largest range by far, but personally I would still consider it

as

an improvement to set up a self-hosted GitLab instance (actually, from a technical point of view, I think GitLab offers even more convenience features for free).

But still, it's right what Eliot said about git and companies:

...

One gives up great autonomy when allowing ones core VCS to be in a

foreign

...

system

So why do you use git & GitHub for OpenSmalltalk-VM and not something like Monticello?

But I do :-) The VM is implemented in Smalltalk and a mixture of other languages but the core VM is *developed* in Smalltalk. See source.squeak.org/VMMaker, and in particular the branch VMMaker.oscog which is the branch of VMMaker that is the trunk of OpenSmalltalk-VM development. Other notable branches from this "trunk" are VMMaker.oscogLLP64, where Nicolas fixed all the work size/pointer size issues for Windows' horrible LLP64 code model (where sizeof(long) != sizeof(void *)), VMMaker.oscogSPC, where I branched to keep the default compactor working while Clément took the mainline along the path to multiple compactor implementations, from which we will derive a production incremental compiler when time allows (see Clément Béra, Eliot Miranda, and Elisa Gonzalez Boix. “Lazy Pointer Update for Low Heap Compaction Pause Times.” In Proceedings of the 15th ACM SIGPLAN International Symposium on Dynamic Languages, 15–27. DLS ’19. ACM, 2019. https://doi.org/10.1145/3359619.3359741) and VMMaker.gdb where Boris is aiming to replace the JIT execution simulation machinery with the gdb framework. And then of course there's VMMaker itself which is the "old" Context Interpreter, plus the flexible 32-bit/64-bit pre-Spur system.

The style of development, plus the things we can do that no one else does, are described in some detail in Daniel Ingalls, Eliot Miranda, Clément Béra, and Elisa Gonzalez Boix. *“Two Decades of Live Coding and Debugging of Virtual Machines through Simulation.”**Software: Practice and Experience* 50, no. 9 (2020): 1629–50. https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.2841. Contact me for a private copy. Suffice it to say that because the VM is developed in Smalltalk both the pace and reliability of development is exceptional, and I speak in the light of my own trivial experience with the BrouHaHa VM which was implemented in C, a series of four VMs that grew out of my early experience at RAL and undergrad student projects, and 12 years at ParcPlace/DarcPlace-Dodgytalk/ObjectShaft/CincompletelyDysfunctional where I architected a VM with the same closure model as we have now, and the transition to 64-bits.

So VMMaker.oscog, in Squeak, is used to develop the VM, and from this C source is generated that comprises one third of the OpenSmalltalk-VM repository. The other two thirds are - a set of platform-specific support files that provide the OS-specific implementation of facilities needed by the core VM, plus (importantly) the implementation of many important plugins, such as the SoundPlugin - a set of build environments to allow us to build on MacOS, WIndows, Linux, Solaris (these are the active ones I'm aware of)

All work on the core VM (the core execution engine, including interpreter, JIT, and core primitives and plugins, and the two memory managers, the old V3, and the new Spur) is done in Smalltalk, and pushed to OpenSmalltalk-VM. All work on the platform sources and build environments is done against the OpenSmalltalk-VM repository.

Were it that Monticello had good file support I would have considered moving the platform sources into Monticello form Subversion, instead of to github. But that would have been a mistake; the integration with modern CI infrastructure is most important. ANd in fact had those behind Tonel been open at the time to make the inclusion of method timestamps possible I would have (and still want to) moved the back end of the VMMaker Monticello system into OpenSmalltalk-VM. It makes sense to have all source co-located. What does *not* make sense is replacing the beautifully integrated and efficient Monticello image experience with the nonsense I see in Iceberg where one has to ape git, checking out a new branch first before branching, etc.

So I have no objection to git/github as being a backend for Monticello. But experience with Pharo and Iceberg, where the promise was made years ago that a Monticello experience would be preserved, and has not been achieved years later with considerable engineering effort available. What they have in Iceberg is, frankly, a mess where git's model and terminology intrude into Smalltalk (I talk from experience having used it with Synchrony Systems late last year/early this).

On Tue, Oct 6, 2020 at 3:48 AM Christoph Thiede < christoph.thiede@student.hpi.uni-potsdam.de> wrote:

Hi all,

looks like I'm a bit late back to this debate again, but it's very nice it is still going on! There are many arguments I wanted to tell but Jakob already explained all of them better than I could do. So just let me come back to some points:

Mantis:

I just took another look at bugs.squeak.org again, and I'm sorry but I still think that our community deserves a better bug tracking solution than this. It really looks old-fashioned and, from today's point of view, quite chaotic and confusing. And compared to something like GitHub, it does not give me an idea of how to report a bug. Do I have to log in? Which credentials do I need to use? Why is there no register button anywhere? Also, there must be some reason why the latest issue was submitted nearly two years ago. Is Mantis connected to the mailing list at all? Asking all of you who have used Mantis in past and reported newer bugs to the mailing list instead, why did you do that? I would guess because mails provid higher visibility and interactivity, is this correct?

Phil, you called GitHub & Co. one trend of many that's durability is uncertain (correct me if I misunderstood you). I see this point, but looking at the current numbers I strongly believe that GitHub has reached a critical mass of developers and projects that won't move so quickly again. How many large global players have decided to use GitHub, including competitors of Microsoft itself such as Google, Apple, Facebook, etc.?

At least, according to the trends GitHub is way more popular than SourceForge, for example, has ever been, actually, it has even overtaken git itself on Google Trends:

https://trends.google.com/trends/explore?date=all&q=github,sourceforge,g...

(By the way, if you search any old threads you can also find it on web.archive.org in most cases).

...

Here you're showing you've already fallen behind: the github trend for discussing things is already fading and those trendier than you have already moved on to the next thing: Slack is where it's at! In a year

or

...

two it will be something else... and the treadmill keeps going but not really going anywhere.

Slack is a group messenger used for communication in small to medium teams, but I can hardly imagine someone seriously uses this as a bug tracker for a large-scale software project with a big community, there is just too much noise when pressing Enter sends a new message. The same goes for social media platforms such as Google Plus that do not even offer basic tracking features such as closing or labeling. I don't think you can compare this.

...

Monticello ancestry does support branching, yet I think Monticello lacks first-class objects for branches, with all the implications for

repository

...

handling.

+1. And I feel the lack of branches for about every second or third submission I make to the inbox and am forced to reinvent my one pseudo branch wheel.

Git vs. GitHub vs. GitLab:

As Jakob already mentioned, they're not the same. I believe that GitHub offers the largest range by far, but personally I would still consider it as an improvement to set up a self-hosted GitLab instance (actually, from a technical point of view, I think GitLab offers even more convenience features for free).

But still, it's right what Eliot said about git and companies:

...

One gives up great autonomy when allowing ones core VCS to be in a

foreign

...

system

So why do you use git & GitHub for OpenSmalltalk-VM and not something like Monticello?

Which leads me to my most important point which Uncle Bob from Jakob's linked talk above gives this striking name to: elitism. In plain theory, I would consider it as an ideal, too, to have a Smalltalk system in which you can literally control every bit (ultimately, this might be a Smalltalk computer with no separate host system, where all drivers etc. are written in Smalltalk - completely neglecting every question of optimization). But in reality, the Squeak community, or even the entire Smalltalk community, is a quite small community, and I would love to change this and make Squeak/Smalltalk competitive again for contemporary development tasks, which involves the mutual boosting between tools/frameworks and developers. And because we are quite small at this point, we have two alternative ways we could go: Either we can spend our time on reimplementing every good and relevant idea from the "real world" in Squeak and making ourself even more comfortable in our small niche (which is, as I'm convinced, already very comfortable in many terms, compared to most other languages and environments); or we can join our forces and focus for now on opening our system towards the real world, both in terms of solutions and people. Which one would you choose?

...

Yet in my opinion Squeak really needs to get along with the outside world for the mutual benefit; we cannot afford to always reimplement everything in Smalltalk just to be able to comfortably debug the issues we wouldn't have if we had used something mature.

+1000

Best, Christoph

PS: And as a matter of course, I'm neither in the position nor willing to enforce any innovations that would deter some of our important community members from the Squeak Project. But I'm not giving up the hope that this discussion may reveal some more interesting insights about the desires and demands of us as a community. :-)

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

Hi,

Now I do not know to which message to reply first :-) and unfortunately most of this is again not about the development process, but at least it is about the experience.

I prefer Git over Monticello not only because Git is more wide-spread and has platforms available to support it. I marked some key points in bold in the following paragraphs in case you cannot afford to read all of it. Sorry to those on plaintext mail clients.

*You can track more objects with Git* (or any unspecialized VCS) *than with Monticello.* As you confirmed Eliot, you cannot track files in Monticello. You also cannot track a Morph or a Readme in Monticello. Instead we need to squeeze everything into classes and methods. You can track anything with Git that you can transform into a tree of blobs. Including Smalltalk code, it is just a special case. Want a new kind of MCDefinition? Git does not care and will store it for you, whatever it is. Monticello, not so easy. (In the end in both cases you would probably have to write some kind of de/serialization to get something nice, but in Monticello you have to modify the VCS, whereas for generic systems you would extend "above" the VCS.)

Using *Git does not imply that you have to use tools outside of the image*. And it does not mean to "be less Smalltalk". Eliot, you asked what I would do if I had unlimited resources. I would improve the Git Browser and accompanying tools so that one could do everything as comfortably as with Monticello, and yet be able to do more than Monticello allows. Well, depending on who you ask, the new tools have already surpassed the Monticello tools in some usability aspects, but certainly not in every way. ;-) But what I meant to say here is that *the long-time Monticello user should be able to feel "at home" even though the repository is a Git repository now*. Regarding the integration of code review, conversation etc. and the tracking of contributions, which got us going here, one can probably build this all in Squeak. There have been projects going in this direction in the past, right Tobias? ;-) With unlimited resources, I would also do that in Squeak because unlimited resources, especially time, means that I could patiently build all the middleware, connectivity, cloud-readiness and OS integration stuff that are more present in the Java, .NET, JavaScript, and Python ecosystems. Or I might try to give those other things more of a Squeak experience, which is one of the things I like about the work Fabio is doing about polyglot programming. Back to reality for now...

Of course *it is possible to have domain-specific tools on top of Git* (or any other suitable, unspecialized VCS), to get a "Monticello expericence" (at least the good parts of it). "Git tools" do not need to stop at the level of file trees and branches of them. I have not used IceBerg myself Eliot, but it sounds like it is on the wrong level of abstraction for your taste. We can have "easy" yet rich and powerful tools in the image with just about any VCS, this is *not a conceptual monopoly of Monticello* (or at least it doesn't have to be). So in my opinion we should go with the most practical (to avoid saying "the best") VCS of the respective time. Squot is built with a certain degree of agnosticism toward the kind of repository, as long as it can store arbitrary objects. The Git Browser of course is somewhat specific to Git, as the name tells. For one because of Git-specifics like remotes, but also regarding the vocabulary on the buttons ("commit", "push", "pull"), to look familiar to Git users (of which there are arguably more than there are Smalltalkers). But we could create a different version of the tool that presents things differently, for sure.

I think a "real" Git backend for Monticello is also feasible, now that we have a usable Git implemenation in Smalltalk already. That's why I brought it up at all. But it would still be a compromise because *Monticello has more quirks* than just being limited to the respective class hierarchy of MCDefinition.

For one, there is this *awful implementation of storage* in Monticello, both on the disk and in memory. What a waste to store the whole snapshot again with each version. And how easy it is to have *a version in the middle of the history missing* from a repository, which makes "diffy versions" dangerous. Git's solution to that (but Mercurial would also be good enough there) is much more space- and time-efficient. You might object that you have to clone the whole Git repository (though there are ways out of that, Microsoft's vfsforgit https://vfsforgit.org/ being one of them), but for the below-Enterprise-scale project it is just not a problem in Git! Copying the whole history of Squeak Trunk on the other hand will probably take longer than to clone an equivalent Git repository, and it will take up more disk space.

Using Git as a backend could solve the efficiency problem in the repository, but *without core changes to Monticello itself, there would still be waste in the image*. This is the reason why we are asked to compress history through less granular commits and contribution reshaping. Quite extraordinary how our tool shapes our process! To refactor this for the better would mean to increase the complexity of Monticello, though. Just as Squot is definitely more complex than Monticello if you count all of Squot's parts (by the way, Squot still uses Monticello for package capturing, loading and image patching, but not the Monticello tools and not the ancestry implementation).

Then there is the delineation of a project. In Monticello, you have to save each package of a project separately. And you may have to create a configuration map on top of that. *In Git* (or just about anything else) *you would just have multiple packages in the tree and save them all together*, and each commit constitutes an implicit configuration of the packages. I think this is a *tremendous advantage in usability*. Many projects consist of more than one package. Yet most of the time the -Core, -Test, -Fluff packages evolve simultaneously. This flaw of Monticello as I am willing to call it is at the core of its model, and therefore also its tools! ("Whew, does anyone remember which version of System corresponds to the changes in this Kernel version...?", because the System version didn't have a number yet when the Kernel version was saved, and therefore was not manually !!! referenced in the log message.)

We already talked about branches. VMMaker is surprisingly just one package, therefore it is easier to create branches through the naming conventions of packages or versions. *Imagine you would have to care about the branch suffix for three or five, let alone 12 or 50 packages* to create and manage a branch of a project. Well, you could create a branched configuration map, but good luck for not letting stuff that belongs to the branch slip into a package that didn't initially get the new naming. Most of the time it seems easier to branch in Monticello by creating a separate repository to hold the branch. This is also something I would consider for a real Git-in-Monticello: to create a branch, create another repo (with the same Git backing); to "push", copy from a local repsitory to a remote repository (and also copy the ancestors along because everything else would be pointless); to merge, well merge the version from the other repo, be it local or remote. Yet this betrays the concept of a repository if you have multiple instances of the same one on your list of repositories. So it still feels like a workaround, just like relying on version name or package name conventions feels to me. I think this is where Eric Evan's book of Domain-Driven Design calls for "Making an implicit concept explicit".

One might also say that branches are not a good idea anyway https://trunkbaseddevelopment.com/ . That there should only be feature flags or really-short-lived branches that are quickly reviewed and then merged. But to have only short-lived branches without the overhead of actual branch management, *we would need better tools to track contributions and a commitment to process them quickly*! The last part might not be feasible even if we had the tools, because you currently cannot earn a living from maintaining and supervising Squeak Trunk development. And about feature flags: I hear we have too many preferences already? ;-)

Now hitting "Post Message" before it's 3 a.m. again...

Kind regards, Jakob

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

Eliot Miranda-2 wrote

In git we have a massive dependence on a black box

Just to make sure it's noticed, once again in a separate email:

We have a usable Git implementation in Smalltalk by now.

Not complete, but serviceable.

If by black box and dependence you mean that we cannot simply turn the Git interfaces and protocols around, true. But we also don't do that in Monticello, and Monticello is simply not spoken by anyone else.

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

Eliot Miranda-2 wrote

On Mon, Oct 5, 2020 at 12:18 PM Jakob Reschke wrote:

...

So either we have that true Git adapter for Monticello (then we would also not need our own server implementation), or the server has a Monticello frontend in front of the Git backend.

If you were architecting this on a tight budget, which would you choose and why?

This one I didn't answer. Starting from what we have today, I would just remove some big dents from the Git Browser and try to create that differently looking GUI variant of it for the "Monticello appeal". Because this does not have the flaws of Monticello I mentioned, but it can have all its benefits, and much of the work has been done already.

Alternatively, try to get this MCGitRepository underway, so you can enjoy whatever you like about the Monticello tools and despise about the Git tools (those in the image, not on the command line), and we could still profit from pull requests etc. on platforms like GitHub, or other kinds of Git integrations. One positive thing about this approach is that it should be possible to copy versions between Git repositories and Monticello repositories as we know them today. The big downside for me in this is that I suspect many will then not even look at the alternative tools and their benefits.

On a tight budget, I think the Git server in Smalltalk is not really feasible in a way that it provides any benefit over a self-hosted GitLab.

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

Hey!

Just for fun, I parsed that schema to see if it would help looking at it in a Squeak ObjectExplorer. Mmmm.. a little, but not really... It's the sheer volume, check out the attached screenshot. I looked for something basic sounding, and came across "User". Look, it has 64 fields! :-o And this is just one of 978 types in total. If you can figure out which of these to map to Monticello's 40 (or whatever it is) types, you could use this parser and Engine in combination with WebServer to host a Git server with MC backend.. MC users could ignore git, while Git users could ignore MC. :-D

To me, it looks very intimidating, though...

[image: Git-parsed-GraphQL-schema.png]

On Mon, Oct 5, 2020 at 1:47 PM Jakob Reschke forums.jakob@resfarm.de wrote:

Hi Eliot,

Eliot Miranda-2 wrote

...

...

On Oct 4, 2020, at 6:14 PM, Jakob Reschke &lt;

...

forums.jakob@

...

&gt; wrote:

...

In other ways, Monticello just looks simpler because something is in

fact

...

...

missing. Consider branches: most Git tools have knobs to deal with them in various ways, while Monticello tools just deny to talk about branches. Monticello ancestry does support branching, yet I think Monticello lacks first-class objects for branches, with all the implications for repository handling. The tools might look simpler without branch management, but it is not a feature but rather the lack of one. Note that you can also avoid branch management in Git: just stay on the mainline branch forever and merge your commits back and forth with the upstream repository's mainline. While it might appear simpler that way, you might as well call it less organized.

Monticello supports branches. And merging between them is as easy as merging any other version of a package. And Monticello does support recording histories across branches.

That is what I wrote: Monticello ancestry does support branching. But there is no list of branches and there is no object for a branch. Instead one has to find the loose ends in a sea of versions. Chris's first tool suggestion would alleviate this, but it may be quite expensive and would still not give names to branches.

Anyway, to have branches was not what Christoph and I were after. Topic tracking and integrated conversations it is.

Eliot Miranda-2 wrote

...

The two things that Monticello has over git are

• that it is used without leaving the image. I’ve yet to see a git

integration where at some stage one was forced to try and fix things in git, or that the image and the git repository got out of sync, or that if one tried to use more than one image against a git repository something horrible broke

• that it can be extended using our own tools. Git is written in C and

controlled by a separate community. One gives up great autonomy when allowing ones core VCS to be in a foreign system. When git crashes it crashes. It doesn’t raise a friendly debugger in which one can determine and fix and proceed from the bug, it segfaults, in optimized code, and you’re hosed.

I can see your point. Although I cannot remember seeing Git crash for me in the last ten years. And we are in a serious lock-in if we extend this notion to everything in the world. I'm glad the other programming languages did not all have to implement their own VCS first, otherwise there would be even more of these around.

Luckily, we already have a Git implementation in Smalltalk. Thank Tobias for urging me to salvage this rather than concentrating on FFI and libgit2 three years ago. The Git Browser tools are as Squeak as they can be for dealing with Smalltalk packages. Except maybe that the Git repository is still stored outside, but what is a commit worth if it gets trapped in an unsaved, unexpectedly broken image.

Even if we didn't have this Smalltalk implementation, the canonical Git has lots of plumbing tools that could be controlled via OSProcess to query and manipulate repositories. It wouldn't crash the VM like errors in libgit2 might, at the cost of being much slower.

Eliot Miranda-2 wrote

...

Personally I don’t want to work in that kind of world. The Pharo crowd do. I will do everything in my power to prevent Squeak going the same way. And if I’m unsuccessful I’ll go somewhere else.

Understood. I don't wish to see you leave.

Yet in my opinion Squeak really needs to get along with the outside world for the mutual benefit; we cannot afford to always reimplement everything in Smalltalk just to be able to comfortably debug the issues we wouldn't have if we had used something mature.

Originally this thread was about the development process and how it can be improved. Sorry for drifting into the Squeak vs. the World discussion again. Some things just trouble me and make me sad.

Kind regards, Jakob

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

Hi Chris,

Thanks for still participating!

Am Fr., 9. Okt. 2020 um 01:33 Uhr schrieb Chris Muller asqueaker@gmail.com:

...

What exactly do you think is so massive about Git?

I wanted to grok git by approaching it via its public API. With my new GraphQL expertise, I figured I could spank out a client prototype in an evening. Then I found the schema:

https://docs.github.com/en/free-pro-team@latest/graphql/overview/public-sche...

Oh, the GitHub GraphQL API is definitely not Git! Git has nothing to say about GraphQL, nor does it say anything about issues, apps, gists, reactions, pull requests, ... just to name a few.

A lot of extra, ignorable features, basically is the definition of over-engineered. Don't get me wrong, it's a great tool for developers with your level of expertise. I'm more of a "user", though, the extra stuff is harder for me.

Git was built with some technical goals in mind and a sane user interface appeared only gradually over its first years. That supports your impression.

Alternative user interfaces have been suggested on top of the data model. https://gitless.com/ for example. The Git Browser uses some of its concepts, such as not having a staging area and selecting what's in and out of a commit while creating the new version, just like Monticello. Gitless is just a different command line UI, everything that is going on in the repository is just the same. Like TortoiseGit and the Git Browser are just different graphical user interfaces, the former for files, the latter for objects.

Conclusion: the "extraneous" features of the tools serve a purpose in their specific context. Since we have a different context, we will build different tools of course. That does not remove any of the advantages of using Git as a repository, or versions database if you will.

A database with advanced tool support out in the world for various needs, such as collaboration supported by platforms like GitHub. That is an option, but it can be a useful one.

I would like to make a pun of the "ignorable" features: the Git index or staging area, for example, is a means to achieve the partial commit feature that Eliot mentioned Vanessa has added to Monticello (i. e. the "ignore" feature). But the Git command line user interface lives in a world of bytes, text, and files (instead of specialized objects) and command lines (instead of graphical tools). You could say that this ignore variable of the MCSaveDialog is the negated equivalent of the index.

Support for branching was added to Monticello in 2012. See MCVersionNameTest>>#testBranches. Eliot used them during development of cog or spur, but I'm not aware of this feature having been all that critical for Squeak. We tend to like just one master branch with occasional releases. But, it's there and basically achieves the needed functionality.

But it is a hidden feature because nothing in the UI indicates its existence, right? This makes it harder to use. Also it is piggy-backed on a different concept (version names), that's why I consider this a workaround about the limitations of the data model.

Also your statement does not address the problems of branching in a multi-package project that I wrote about in the earlier long message.

I thought the social benefits (exposure and growth, I guess) were via exposure to the github user base. If we hosted ourselves, would it be any different than the "deserted island" situation we have now? That's all what I was referring to. I thought the purpose was for the exposure. If you have to host yourself anyway then we're basically down to a tool comparison?

You do not *have to* host yourself. :-) But you could if you don't trust the corporate (yet very open-source-supporting) GitHub.

The social benefits of exposure do also exist, but it was not in the focus of this thread. That was an improved development process with regards to the easier tracking of contributions. For example, if you re-work your inbox submission and create another version, it will open another thread on the mailing list, with no traceable connection to the previous conversation. Not so with pull requests on GitHub (or whatever they are called on the alternatives to GitHub), if you update your submission on the same branch (even if you replace the commits that you sent before), the old conversation is still attached to the pull request.

By the way, that is something you could trace via that exhaustive GitHub GraphQL API if you wanted to build a Squeak interface to GitHub pull requests. ;-) Sure it seems overwhelming, but who says that you have to consume and support it all? It just offers a lot of options, at your service... I don't think this is a bad thing.

...

Chris Muller-3 wrote

...

For example, you could submit an improvement that allows original contributors of Inbox items to move them to Treated themself.

How? Only Trunk committers have access to the Squeaksource treating backend, so neither the code nor the tool is available to normal users for improvement. Guest users cannot even delete versions from the inbox repository, can they?

It's public read, anyone can access the code and submit improvements to the Inbox. But, I agree, it'd be nice if there were a way for strangers to contribute more obviously. One idea would be for each SqueakSource repository to have it's own internal "Inbox" Repository to support some of these features...

That would be a nice first step towards something like pull requests for projects other than Trunk. But you didn't address that submitters cannot move their own contributions to Treated, even if they wanted to.

The point is Monticello is relatively small, simple, and malleable, and this makes it feasible to improve, even if getting it implemented requires writing email.

Tools on top of the Git data model would also be malleable. Writing email is not the primary issue here (except for the generational favoring of platforms over mailing lists maybe). Integrating the conversation with the code contributions is. As we said, if we were to use GitHub, we should make sure to tie in the conversations there into the mailing lists, just like it has been done for OpenSmalltalk-VM.

Monticello does suffer from some scalability issues that will eventually need to be addressed.

When is the eventual time?

Git is one possible solution to the scalability problem. One solution where you don't have to reinvent the hosting software. One solution that already has a pure-Smalltalk implementation.

But the redundancy among versions is a feature, not a flaw. To this day, planes have poor internet access, this redundancy is about availability. In the Magma-based, there is only one instance of each MCDefinition shared amongst all Versions, but not everyone set that up on their laptop (I made it as easy as I could).

Git uses similar value object sharing in its data model. :-) And if you clone a Git repository, you have it right on your laptop. If you download a single Monticello version and go offline, you just have one snapshot and an ancestry where you cannot look at the past snapshots. With a Git repository, you typically have everything at your hands.

Of course you shouldn't clone the repository just to install some package (as opposed to develop it). The download-to-install use case is typically satisfied by explicit releases where you put an archive or installer somewhere. Monticello also fills this role currently, next to SqueakMap. In the Git world, there are typically web interfaces that allow you to download just one particular snapshot. Metacello uses the particular HTTP interface of GitHub to download a zip, for example.

What I had wanted to do start by sucking in their GraphQL schema into my fantastic new GraphQL Engine, and map their types to the Monticello types. Basically appear to BE a Git server, but mapped behind the scenes to legacy MC repos that could be accessed via the legacy way, for users that wanted to.

Hmm this breaks down because that schema is not just about Git, it is also about all of GitHub as indicated above. So your server that implements the whole schema would really be another GitHub server, not another Git server.

The basic objects of Git are just blobs, trees, commits, tags, and refs. But this is not the abstraction level of an MCDefinition. There is no point to have an MCTreeDefinition. Instead you would map your MCSomethingDefinition into a tree of blobs and store that in the Git repository. Blobs, trees, and commits would be handled by the MCRepository subclass and something like the MCWriters and MCReaders instead. Does this make sense to you?

To be a Git server, you need to be able to manipulate repositories and to provide the fetch and push interface. For repositories, the Smalltalk code is already there. For the interface, only the client side of the protocols is implemented in Smalltalk yet.

Kind regards, Jakob

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@gmail.com: On Mon, Sep 28, 2020 at 10:07 AM Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]> wrote:

Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de [mailto:Christoph.Thiede@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

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 karlramberg@gmail.com: 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@hpi.de [mailto:marcel.taeumel@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@gmail.com [mailto:asqueaker@gmail.com]>: On Mon, Sep 28, 2020 at 10:07 AM Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]> wrote:

Hi Christoph,

On Fri, Sep 25, 2020 at 7:58 AM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de [mailto:Christoph.Thiede@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