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.
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
- providing a branch button in the commit dialog which would provide a name template with the string '<branchname>' for one to edit
- providing a "merge branch" operation that would offer only to merge the changes from the branch against the most recent common ancestor
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?
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.
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.
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...
> 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