So what would be the alternative? A centralized server (e.g. Cincom Public Repository, SqueakSource, SmalltalkHub, SqueakSource 3). After that, all you need is a detailed project/package/framework description. Google will index it.
The whole "GitHub adventure" was started on the premise that it would give Pharo more visibility. I don't see how it differs from SqueakSource from a visibility standpoint unless you specifically search for code only on GitHub. Most people just google anyway! Besides, Smalltalk code on GitHub leaves a very bad impression on newcomers. I was recently told "I just gave up on Smalltalk when I saw 200+ files"... It was too late. I told the poor guy it was just the way code was *stored* on GitHub but in your dev environment, everything resides in the image... Too late : I had lost him solely based on the impression that he was entering into a code management nightmare worse than a thousand C header files! In the current state of things, the whole Cuis/Pharo/Squeak world is a mess. Newcomers looking for code end up having to pick between a myriad of links to SqueakMap, catalogs, SqueakSource, SmalltalkHub, SS3, GitHub, sar files, mcz files, fileOuts, etc. Ever tried to do some database stuff with Squeak or Pharo? Just try to pick a package that works! You'll find plenty of code on all platforms (SqueakSource, SqueakMap, SS3, GitHub), many ports from one to the other and, in the end, you'll have tried to load 8 packages without success... Wouldn't it be nice to have a centralized server with Cuis, Pharo, Squeak (and/or others such as VW, VAST, Dolphin) and share a common import/export format (SIXX, Smalltalk Instance eXchange in XML, would be a good start and would probably do a decent job) and have the capability to store *other files* as well (such as config files, source code in other languages, SQL scripts, etc). Something with the functionalities/capabilities of Store (VW code management) with code store in a portable format. My 2 cents.  ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein) From: Norbert Hartl <norbert@hartl.name> To: Pharo Dev <pharo-dev@lists.pharo.org> Sent: Saturday, January 13, 2018 7:13 AM Subject: Re: [Pharo-dev] Blame support P7 Am 13.01.2018 um 12:39 schrieb Eliot Miranda <eliot.miranda@gmail.com>: Hi Stephan, On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan@stack.nl> wrote: Eliot Miranda <eliot.miranda@gmail.com> wrote: Isn't it important to preserve the ability to exchange code between Pharo, Squeak and Cuis?  Don't you care that the VM development is directly affected by this?  Is the VM and plugin support not important to Pharo? Git support turns out to be much more work than we hoped and expected. Too many library updates needed, support for different workflows and platforms, switch to file per class. The Iceberg channel on Discord is one of the busiest channels. You don't say?  One of Clément's themes in recent talks on VM performance is that we, as a very small team, are able to develop such a sophisticated optimizer because we use Smalltalk.  We are hugely productive in the vm simulator.  People using Smalltalk, including the Pharo, Squeak and Cuis dialects that constitute our community, report the same in many different domains, notably Bloc, GT Toolkit and Rossal. Then why on /earth/ would one stop using Smalltalk in /the most central part/ of the collaborative programming process, version control?  This is a huge blunder.  Now a major part of the Pharo community's efforts goes into an external component, upon which Pharo is entirely dependent, and slowly but surely it is cutting itself off from its sibling communities.  Iceberg is well named.  People rearranged the chairs on deck while the Titanic sank. Can we agree that a class/method/⦠stops being smalltalk after it has been serialized to text? If you can agree to this I donât know what you are talking about. We exchange the to-text-serializer monticello-backend with git-backend. The rest (the important part) stays nearly the same. The exchange is necessary because the possibilities of collaboration are limited when using monticello only. So what would be the alternative?There are even a lot of people that donât like git (including me). But I like the collaboration model because that can do what no smalltalk tool can do to my knowledge. Or to turn your argument around. You are a small vm team and you have to be small because I doubt with the current collaboration model you are able to grow. Norbert Stepha _,,,^..^,,,_ (phone)