[Cuis] Why not just kill changesets?

[Casey Ransberger]

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

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:

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.

- Stuff I've missed.

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.

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

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

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130101/5410a06c/attachment-0001.html>