[Cuis] Why not just kill changesets?

[H. Hirzel]

P.S. Actually what we should do is an analysis how many classes we
have per class category in the Cuis core and which categories besides
the test categories are candidates for offloading into a *.pck.st file
(as for example sound).

Could somebody paste a code snippet which does this please?

     SystemOrganizer new categoriesMatching: 'Tests'

gives a walkback....


Having more *.pck.st files and less classes in the core would reduce
the frequency of change sets for the core as there is less to fix.

--Hannes

On 1/2/13, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> 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
>