<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'>My opinion for what it us worth.<br><br><br>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*<br><br>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.<br><br>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**<br><br>Count me in the keep monticello camp, and also count me in the outreach/facilitate camp. <br><br>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.<br><br>Cordially,<br><br><br><br><br>*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 <br><br>https://slackbuilds.org/repository/14.2/desktop/e16/<br><br>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.<br><br><br><br>**cue Tim screaming....<div id="message"></div><br id="br3"><div id="signature"></div><div id="content"><br> ---- On Tue, 06 Oct 2020 06:47:58 -0400 <b> christoph.thiede@student.hpi.uni-potsdam.de </b> wrote ----<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); padding-left: 6px; margin-left: 5px;"><div>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 bugs.squeak.org 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" 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>web.archive.org 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><br><br>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><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" target="_blank">http://forum.world.st/Squeak-Dev-f45488.html</a><br><br></div></blockquote></div></div><br></body></html>