<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:large">Hi Christoph,<br></div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">    I answered your Q's about OpenSmalltalk in another thread. But to your other points, c below...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 6, 2020 at 3:48 AM Christoph Thiede <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de">christoph.thiede@student.hpi.uni-potsdam.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
looks like I'm a bit late back to this debate again, but it's very nice it<br>
is still going on! There are many arguments I wanted to tell but Jakob<br>
already explained all of them better than I could do. So just let me come<br>
back to some points:<br>
<br>
<br>
Mantis:<br>
<br>
I just took another look at <a href="http://bugs.squeak.org" rel="noreferrer" target="_blank">bugs.squeak.org</a> again, and I'm sorry but I still<br>
think that our community deserves a better bug tracking solution than this.<br>
It really looks old-fashioned and, from today's point of view, quite chaotic<br>
and confusing. And compared to something like GitHub, it does not give me an<br>
idea of how to report a bug. Do I have to log in? Which credentials do I<br>
need to use? Why is there no register button anywhere?<br>
Also, there must be some reason why the latest issue was submitted nearly<br>
two years ago. Is Mantis connected to the mailing list at all? Asking all of<br>
you who have used Mantis in past and reported newer bugs to the mailing list<br>
instead, why did you do that? I would guess because mails provid higher<br>
visibility and interactivity, is this correct?<br>
<br>
<br>
Phil, you called GitHub & Co. one trend of many that's durability is<br>
uncertain (correct me if I misunderstood you). I see this point, but looking<br>
at the current numbers I strongly believe that GitHub has reached a critical<br>
mass of developers and projects that won't move so quickly again. How many<br>
large global players have decided to use GitHub, including competitors of<br>
Microsoft itself such as Google, Apple, Facebook, etc.?<br>
<br>
At least, according to the trends GitHub is way more popular than<br>
SourceForge, for example, has ever been, actually, it has even overtaken git<br>
itself on Google Trends:<br>
<a href="https://trends.google.com/trends/explore?date=all&q=github,sourceforge,gitlab,bitbucket,slack" rel="noreferrer" target="_blank">https://trends.google.com/trends/explore?date=all&q=github,sourceforge,gitlab,bitbucket,slack</a><br>
<br>
(By the way, if you search any old threads you can also find it on<br>
<a href="http://web.archive.org" rel="noreferrer" target="_blank">web.archive.org</a> in most cases).<br>
<br>
> Here you're showing you've already fallen behind: the github trend for<br>
> discussing things is already fading and those trendier than you have<br>
> already moved on to the next thing: Slack  is where it's at!  In a year or<br>
> two it will be something else... and the treadmill keeps going but not<br>
> really going anywhere.<br>
<br>
Slack is a group messenger used for communication in small to medium teams,<br>
but I can hardly imagine someone seriously uses this as a bug tracker for a<br>
large-scale software project with a big community, there is just too much<br>
noise when pressing Enter sends a new message. The same goes for social<br>
media platforms such as Google Plus that do not even offer basic tracking<br>
features such as closing or labeling. I don't think you can compare this.<br>
<br>
<br>
> Monticello ancestry does support branching, yet I think Monticello lacks<br>
> first-class objects for branches, with all the implications for repository<br>
> handling.<br>
<br>
+1. And I feel the lack of branches for about every second or third<br>
submission I make to the inbox and am forced to reinvent my one pseudo<br>
branch wheel.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:large">I don't understand/  To branch all you do is add a dash and a name after the current branch.  It seems to me that we want to surface that Monticello supports branches by</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">- providing a branch button in the commit dialog which would provide a name template with the string '<branchname>' for one to edit</div><div class="gmail_default" style="font-size:large">- providing a "merge branch" operation that would offer only to merge the changes from the branch against the most recent common ancestor</div><div class="gmail_default" style="font-size:large"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Git vs. GitHub vs. GitLab:<br>
<br>
As Jakob already mentioned, they're not the same. I believe that GitHub<br>
offers the largest range by far, but personally I would still consider it as<br>
an improvement to set up a self-hosted GitLab instance (actually, from a<br>
technical point of view, I think GitLab offers even more convenience<br>
features for free).<br>
<br>
But still, it's right what Eliot said about git and companies:<br>
<br>
> One gives up great autonomy when allowing ones core VCS to be in a foreign<br>
> system<br>
<br>
So why do you use git & GitHub for OpenSmalltalk-VM and not something like<br>
Monticello?<br>
<br>
Which leads me to my most important point which Uncle Bob from Jakob's<br>
linked talk above gives this striking name to: elitism.<br>
In plain theory, I would consider it as an ideal, too, to have a Smalltalk<br>
system in which you can literally control every bit (ultimately, this might<br>
be a Smalltalk computer with no separate host system, where all drivers etc.<br>
are written in Smalltalk - completely neglecting every question of<br>
optimization). But in reality, the Squeak community, or even the entire<br>
Smalltalk community, is a quite small community, and I would love to change<br>
this and make Squeak/Smalltalk competitive again for contemporary<br>
development tasks, which involves the mutual boosting between<br>
tools/frameworks and developers. And because we are quite small at this<br>
point, we have two alternative ways we could go:<br>
Either we can spend our time on reimplementing every good and relevant idea<br>
from the "real world" in Squeak and making ourself even more comfortable in<br>
our small niche (which is, as I'm convinced, already very comfortable in<br>
many terms, compared to most other languages and environments); or we can<br>
join our forces and focus for now on opening our system towards the real<br>
world, both in terms of solutions and people. Which one would you choose?<br></blockquote><div><br></div><div class="gmail_default" style="font-size:large">I agree.  But this is not about reinventing the wheel.  This is about whether we discard a rather beautifully crafted wheel that is one of the main supports and propulsive engines we have for an uncertain future based on git.  And I am not encouraged by the Pharo exerience.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">In Monticello we have something that works *very well*, something that can be extended quickly (look at Vanessa's beautiful selective check-in facility, which mimics git's add/reset staging functionality but in a much lighter-weight and better-integrated way, which Vanessa was able to implement quickly and which I believe involved a single commit for trunk and has worked flawlessly ever since).  In git we have a massive dependence on a black box, which, if one looks at the Pharo community has changed entirely their SCM experience, and not for the better.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">So other than SCM, I agree we should not be reinventing the wheel.  But in proposing we move to git you're actually suggesting we get rid of our wheels and go back to rolling logs...</div><div class="gmail_default" style="font-size:large"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> Yet in my opinion Squeak really needs to get along with the outside world<br>
> for the mutual benefit; we cannot afford to always reimplement everything<br>
> in Smalltalk just to be able to comfortably debug the issues we wouldn't<br>
> have if we had used something mature.<br>
<br>
+1000<br>
<br>
<br>
Best,<br>
Christoph<br>
<br>
PS: And as a matter of course, I'm neither in the position nor willing to<br>
enforce any innovations that would deter some of our important community<br>
members from the Squeak Project. But I'm not giving up the hope that this<br>
discussion may reveal some more interesting insights about the desires and<br>
demands of us as a community. :-)<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://forum.world.st/Squeak-Dev-f45488.html" rel="noreferrer" target="_blank">http://forum.world.st/Squeak-Dev-f45488.html</a><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>