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