Hi, If anyone *ever* thought we are moving to git because is the new stuff, I need to clarify several things:
1) you don’t know me :) 2) git is not new-cool stuff since a couple of years so is not that we are jumping into anything fancy shiny new (we should be trying to use docker as monticello repositories if that would be the case). Now, let’s talk for real: suppose for a second that you are a software architect (whatever that means) that has in your shoulders the responsibility of drive forward this amazing project called is Pharo. Pharo is a HUGE project with a lot of composants all of them moving. Many times because people introduces changes, others because changes affects others (this is not cool, but happens a lot) and some other simply time passes and world changes around us, which also makes our vision of things change. Now, in this context, as a software architect you do an analysis of risk and you get that Pharo has a lot of them, I will quote just a couple: - As a “moving target”, maintainability is the first big issue: the accidental complexity of the system tends constantly to increase (sometimes, as with some version, at speeds you wouldn’t believe it). Also, incorporating new tools means new things to maintain, constantly. - We do not have enough resources. No idea if we will ever get enough resources, but we do not have enough people to keep maintaining everything and in addition iterate to evolve Pharo. Of course we benefit of been a large community with many people contributing but that is an advantage but also a risk. - People pushes their own agendas. This is perfectly ok, but that means the effort is not measurable nor dirigible :) - tools are OLD. Many of them (including monticello) were built for a world who do not exists any more: software projects are *different* now: bigger, multi-platform, multi-language, N-tier, etc., etc. etc. - … (I can continue all day detecting risks) Now, always as a software architect, you detected an important amount of risks that can make fail your project, and then you have to take decisions to mitigate this risks. One possibility is stop moving. Freezing that part will add a lot of stability to the system… just we will using a relic, and the world will continue changing… others have followed this path. Pharo vision is (and has always been) other… we need, we want to continue moving. So this solution cannot be taken. Other solution is to hire more people. Of course, no money and no money means no more people. Another solution that cannot be taken. So we arrive to a third solution: Reduce the amount of things that needs to be maintained and are “non essential”, so we can concentrate in developing what is actually our thing: we do Pharo. Replacing Monticello with git goes in this direction: - it allows us to stop maintaining sthub (or any other pharo-based repository). Let’s face it: we will NEVER develop a tool as good as github/gitlab/bitbucket/the next thing. Why? Because it is NOT OUT BUSINESS. They have developers there, who’s only work is to do such tool. - but also: it allow developing sotfware projects in ways monticello don’t: multi language, external sources, etc. - but also: it allow CI without us needing to maintain jenkins (another thing that we will able to not maintain anymore… I spent far too much time there and I spent 1% of the time that Christophe spent there, for example). - but also: it reduces the level of “alieness” that newcomers experiments when they arrive to Pharo (let’s face it: most people arrives to Pharo already knowing other languages and most of them are expecting a file-based way of sharing… many of them are expecting git, in fact). In other order of things: - I spent last week replacing a backend made in amber with a backend made in seaside just to remove amber from the equation: so something we need to maintain is pharo-exclusive (this is “architecture 101”: systems complexity increases exponentially for each language you add). - I spent last 3 months aligning the PharoVM with the CogVM, removing what was a “de facto” fork, just to reduce the amount of maintenance effort we need to put there. And to join efforts with Eliot and all others (because joining a larger team and collaborate with them is also a way to incorporate more people into our own VM). - I spent months developing UFFI to remove NativeBoost from the equation with exactly the same purpose: reduce the amount of things we need to maintain. So, as Pharo architect, Pharo fireman, stabilisation faery, whatever you want to call me, it is my responsibility to be sure Pharo will continue moving forward, and this is my answer. But not just me. I work on RMoD team at INRIA. The research team purpose is precisely to support “software evolution”. This means I have the luck of work with some of the best people in the world to ask for this kind of questions. And there is also the Pharo board, who is a group of professionals who knows a bit about pharo and software projects developing. So yes… if you ever thought we are people who jumps to the new-hyped-thing just because is there… think again. Esteban > On 7 Nov 2016, at 07:48, p...@highoctane.be wrote: > > Mcz repos are useful. > > STH storage works nicely, that's more the frontend which si bitrotting. > > I actually have a local FTP based thing on my Synology and it is neat and > needs no time to work. > > Did you ever look into Zinc and see there is also a server there for that? > > Now, GitHub is better for sharing as there is the *critical mass* there. And > the tooling is very good. > > And we can stuff a lot of other things than mcz in it (and with Git LFS > https://git-lfs.github.com/ <https://git-lfs.github.com/> we could even stuff > images and mcz in there right away. This thing is next in line for inclusion > in https://github.com/Pharophile/ExternalTools > <https://github.com/Pharophile/ExternalTools> > > In pvt chats on Slack, there is this tension between moving forward and > stabilizing stuff. I hope that with boostrap, we'll be able to have a stable > core and LTS assemblies. > > Reinventing the wheel is fun. But it better has to be a better wheel. > > Let's alway thing about our "normal" > https://www.youtube.com/watch?v=FvmTSpJU-Xc > <https://www.youtube.com/watch?v=FvmTSpJU-Xc> > > We are at risk of boiling ourselves, in whatever plane we are. > > I like the progress and I hate to have to adapt. But once past the curve, > life is actually better. Lots. > > Phil > > > > > On Mon, Nov 7, 2016 at 5:29 AM, Igor Stasenko <siguc...@gmail.com > <mailto:siguc...@gmail.com>> wrote: > > > On 6 November 2016 at 17:21, Stephan Eggermont <step...@stack.nl > <mailto:step...@stack.nl>> wrote: > Kilon wrote: > > If you really want to embrace Github , kill Smalltalkhub > > We are not close to doing that. We'll need > Monticello support indefinitely, and at least a few years two-way. And that > assumes we automatically migrate all open projects. > > First we need good workflows that also work for complex projects. That > includes cross-platform projects like Seaside > > > Oh, come on! Throw away everything you had.. and start using something new > and trendy, rinse and repeat. Profit! > :) > > Stephan > > > > > > > -- > Best regards, > Igor Stasenko. >
