[Cuis] Why not just kill changesets?

[H. Hirzel]

On 1/2/13, Casey Ransberger <casey.obrien.r at gmail.com> 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
>
> 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:)

How did you do it at that time?

 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.

OK

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

My first reaction. ChangeSets are patches and patches and core goes
together fine, right?

However I agree that the core should be made smaller. See my
suggestion about removing Morphic and having only a two-pane GUI from
which to load a Morphic.pck.st file.

For convenience I attach the screen shot again. Then at least change
sets regarding Morphic would be eliminated.  Of couse the first thing
people have to do then is to run load scripts to get a useful image to
work with.





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

At the moment I do not have too much problems with this. But you are
right,  the question is: how can we make better of github. As
discussed just these days, we need some time to get used to the new
model of working with github.

Suggestion: Investing time for git learning is surely not wasted (at
least 5..12 hours ). We can do mini-examples on github with
repositories we fork and later delete again.

Such a mini-example could be to unload all tests into their
corresponding *Test*.pck.st packages hosted on github (in a branch of
the main Cuis) This would avoid having test updates in the core change
sets.


> - We can completely unload (at least a lot) of the changeset handling
> machinery*

Not instantly, maybe later  :-). I do not think it is all that much
code but I have not checked.

> - Smalltalk effectively becomes a peer to kernels which manage code in
> files, which makes us a lot less of a scary monster to newcomers.

Sure, and in fact this is not so new at all
see https://github.com/bonzini/smalltalk

A 1200 classes image is a bit daunting whereas a 500..600 classes
image is much less. As it was in the olden days (e.g. Smalltalk V/ for
DOS). Thus all these efforts of 'Little Smalltalks' etc.

Did somebody check recently how many classes the basic GNU Smalltalk image has?

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

Please see my other thread, I'd like to have it working.....   :-)
Maybe it is and Juan has updated it when doing 4.1


--Hannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProposalForMinimalMorphicGUIforCuis4.1.png
Type: image/png
Size: 33717 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130102/08e400fd/attachment-0004.png>