tedious programming-in-the-debugger error needs fixing

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

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

I already have some early plans about this lying on my desk how such an integration system could look like. Schematically, we would need to observe the list of pull requests in the git repository and mirror every new commit as an inbox version to the inbox. The other way around, the Monticello list of inbox/trunk versions needs to be observed, and all new versions that were not already triggered by a PR need to be converted into a new git commit either on the main branch or on a PR branch. Conversation could be synchronized using the OpenSmalltalk-VM-Bot.

Ideally, this approach could allow us to operate with the same version & issue model from two alternative views, Monticello+mailing list, and GitHub.

However, that's only a thought experiment at this time, and everything further would probably be an implementation detail only. 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.

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

I don't think so, too. While I appreciate the idea of using true Smalltalk objects for every part of the Squeak project, including issues and versioning, it is simply not realistic for a community of our size to build a full-stack service from the scratch for these aspects, again, that can compete with big existing solutions such as GitHub & Co. Thus, my personal opinion would be to outsource it.

Best,

Christoph

> Agreed. Elitism does not help at all. Ask Uncle Bob [1].

Great talk, thanks a lot for sharing this!

Hi Jakob,

> On Oct 4, 2020, at 6:14 PM, Jakob Reschke <[hidden email]> 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 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,gitlab,bitbucket,slack

(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