Re: Golang mudules to follow common grouping

[Christina O'Donnell]

Hi Oleg,
     
> I've pushed the split III to master.

Fantastic work!
> I think you may help! The identification of the group is still human
> decision making process and I'm not sure it may be automated in any point.

I can certainly help with this then. I'll have some free time on Friday and
I can coordinate with you then.
    > Each of the module header contains a
        short annotation which packages it 
      >
        expects to have, feel free to improve it to make it even more
        clear 
      > for
        others.
      >
      
      > -
        golang-check 
      > -
        golang-web 
      > -
        golang-crypto 
      >
      
      > TBA:
      
      > -
        golang-compression :: Anything related to that subject, see
      
      >  
        python-compression, java-compression, perl-compression. 
      >
      
      > -
        golang-build or golang-extension :: Any low level golang add-ons
        not 
      >
        included in core distribution see
        <https://pkg.go.dev/golang.org/x> or 
      > any 0
        dependencies high reference modules. 
      >
      
      > -
        golang-xyz :: As any other *-xyz module would absorb anything
        else 
      >   left
        behind. 
      
      This all sounds sensible to me.
      
      >> 1.
        Put a magic comment above each package that you would like to
        move. 
      >> 2.
        Run a simple script that makes a note of all of these into a
      
      >>
        to-move-list. 
      >> 3.
        Then stash the change with the comments you made (in case you
        need 
      >> to
        change things) 
      >> 4.
        Run another script that takes the package list and performs the
      
      >>
        move in one's repository. 
      >> 5.
        Sort out the use-package declarations manually and run tests.
      
      >> 6.
        When satisfied, stash the change and keep just the use-package
      
      >>
        changes. 
      >> 7.
        Run a final script that loops through all the packages and
        commits 
      >>
        each one in turn. 
      >> 8.
        Rebase to suit. 
      >
      
      > We may
        extend handy script accelerating committing process, see
      
      >
        "etc/committer.scm" 
      
        Okay, cool, I'll have a look at it on Friday.
       
      >> -
        I'm not a scheme programmer, but I did use Haskell at university
        so 
      >>
        I'm familiar with thinking in a functional style. 
      > Me too
        =), but you still can help by just providing some review to
      
      >
        existing code base and available packages in golagn.scm and
        trying to 
      >
        identify close group for each of them. 
      >
      
      >>
        I'm also imagining some the possibility of having a script that
        can 
      >>
        remove redundant #:use-module's in the future, though I don't
        know if 
      >> we
        care about a few unneeded modules being included. 
      > The
        clean up task may be organasied after sort process is completed,
        having 
      > not
        required #:use-module does not hurt too much but for keeping
        modules 
      > tidy
        and fast to load it definitely beneficial. 
      
      
      This makes sense. Not a priority at present but a nice-to

Looking forward to hacking golang.scm to pieces!

Kind regards,
 - Christina