Hi Christoph,

    I answered your Q's about OpenSmalltalk in another thread. But to your
other points, c below...

On Tue, Oct 6, 2020 at 3:48 AM Christoph Thiede <
christoph.thiede at 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.
>

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

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201006/a4db2aaf/attachment.html>