[Cuis] Why not just kill changesets?

[Juan Vuletich]

Ok. This will be long :)

Casey Ransberger wrote:
> Now that I've wrapped my head around the new Git Cuis dev model, I 
> would recommend grabbing a healthy supply of torches and pitchforks, 
> because I think I'm reaching for a Third Option here. So we're all on 
> the same page about what that means:
>
> http://tvtropes.org/pmwiki/pmwiki.php/Main/TakeAThirdOption

Thanks for the link. Sometimes I have trouble following the stuff you quote.

> I thought about sending this straight to Juan, but why not, whole 
> list. I expect that Juan's arguments will be interesting in this case.
>
> Alright! What do we really need changesets for then? Why not make 
> developing the core the same as developing anything else? So if we 
> killed changesets:

Ok. It is a good question. I'll interleave some comments on your 
Cons/Pros, and then add mine.

> Cons:
>
> - We'd have to engineer our way around the "breaking the update 
> stream" problem. This is work, but I'm sure it's doable. I did it 
> once:) and ContentPack happened because I needed to do a spot of time 
> travel to fix the update stream after I broke it. If I can travel 
> through time, I'm pretty sure we can handle a bootstrapping problem. 
> Especially given that we have the computational equivalent of a TARDIS 
> at our disposal.
>
> - Cuis now depends completely on Git. Note: Git is *extremely 
> popular,* not likely to go the way of the dodo any time soon, and 
> maintained like the Linux kernel matters to Linus. Also, switching to 
> another SCM should be relatively trivial when necessary, if not 
> painless. And: Git presently runs most places where Cuis runs.

Ehhh. No. Cuis doesn't depend on Git at all. We use Git as a shared, 
universally accessible repository. We also use it to version files, and 
to ease teamwork. But Cuis is not tied to Git. All Cuis needs is a local 
file system to store files (obviously, a local clone of a Git repository 
works).

> - Stuff I've missed.

I add some cons. But before that, I see two ways here. One is to have a 
really small kernel, and load stuff to build images (the Pavel way). The 
other one is to have a bigger image, with packages always loaded, and 
load new versions of packages on top of old ones to update the images 
(the Squeak way). So:

=== Cons (a) miniKernel + loadable packages. Pavel's way:

- The artefact is no longer a Smalltalk-80 system. This is very 
important to me. Smalltalk-80 is a huge landmark in the history of 
computing. One of the main reasons I do Cuis is to preserve and spread 
this legacy. This is the best tribute I can do to Smalltalk-80 and its 
developers.

- Not having the dev tools in the image makes modifying it harder.

- We're not showing newcomers the beauty of the Smalltalk system, but 
just a bunch of files they need to 'make' in order to have something useful.

- The mini-kernel will also need modifications from time to time. How do 
we do that? With ChangeSets?

- Maintenance will take more work. We'd need procedures to update or 
re-create the kernel, build the distributions, QA them, etc.

- As the only way to update an image is to rebuild it from scratch, 
people wouldn't be able to update their own images. To allow for this, 
we also introduce the Cons of (b), below.


=== Cons (b) Packages always loaded. Squeak's way:

- We'd need a package loader with atomic loading. Squeak doesn't yet 
have it, after a decade of using Monticello.

- We'd need version, dependency, and version dependency control. 
Otherwise, it is not just optional package loading that becomes fragile, 
but the base system itself.

- It would be difficult and dangerous to update the Kernel and 
PackageLoader packages.

- In Squeak, we end having package postcripts, and strict load ordering 
of package version. Loading intermediate versions is required. There is, 
after all an update stream, but instead of a small set of changes, each 
update includes all the code. It becomes an huge monster that nobody can 
audit.

- Updating an image becomes muuuuuuch sloooooweeer.

- When updating an image it is much harder to understand what happened, 
to adapt our code.


> Pros:
>
> - No more confusing dichotomy between what's core and what isn't; 
> everything becomes a package, and lives in whatever repository is 
> appropriate. Symmetry. Exactly one way to manage code. Kernel can be 
> reduced to a bloody stump which has the singular ability to load in 
> other packages (attach limbs.) Epic win for modularity.
>
> - No more annoying dialogs about unsaved changes in core when there 
> aren't actually any. Everything is a package, so there isn't a 
> distinction. We don't need a special method to determine what's part 
> of core and what isn't WRT the warnings about unsaved changed. 
> Elegance, symmetry, less blivet to worry about.

This is unfair. I answered (I believe twice) about your concerns with 
those warnings, but didn't get a response from you! Please, let's 
discuss those warnings in a separate thread. If we have some use case(s) 
and some discussion, I believe we'll clarify any doubts and come up with 
something that works well for everybody.

> - We can completely unload (at least a lot) of the changeset handling 
> machinery*
>
> - Smalltalk effectively becomes a peer to kernels which manage code in 
> files, which makes us a lot less of a scary monster to newcomers.
>
> - Stuff I've missed.
>
> *Actually, I could be wrong about this part. Probably the Git stuff is 
> using a lot of it. But I'll bet a single US dollar against the first 
> of you who says killing changesets won't eliminate some net (as 
> opposed to "gross") code, even if I might lose a dollar for dreaming 
> too hard.

We can see Squeak's experience with eliminating ChangeSets, and Pharo's 
experiments with Pharo-Core. Let's learn from them.

> I mean, why do anything halfway;) ?
>
> Okay, so I'm totally locking the doors. It's always raining in 
> Seattle, so rebooting the Frankenstein monster shouldn't be hard, I 
> just have to wait for some lightning. If you try creeping up on me, 
> I'll be able to see your torches, so that's not gonna work. Email is 
> the best plan!
>
> I can't wait to see what people think about this. Really, it's about 
> whether or not managing code is or is not Smalltalk's problem in the 
> modern world: and that's a hell of a question to talk about, or I 
> think so. I think it's genuinely an important, and open question, 
> specifically in this small community.

Sure.

> At this point, we're almost more of a quorum than a community, and so: 
> if we want to do this, we might be able to tackle it, if we as a group 
> found it sensible, before senseless convention takes over and becomes 
> effectively permanent, rigid.

I agree. This is the best time to evaluate all possible options.

> Okay now's the time to use your torches and pitchforks. I'll be hiding 
> under the couch. In an unspecified apartment in Seattle. Go.

:) I hope tolerance and respect for everybody's freedom wins.

Cheers,
Juan Vuletich

> P.S.
>
> I presently have low confidence that ContentPack still works right 
> presently:( and I'm okay with that, but either I've got to fix it or 
> we should unload it and move on.
>
> -- 
> Casey Ransberger