Re: Hoisting other libraries from M2BSK?

[Alice Osako]

    Benjamin Kowarsch:

On Sun, 24 Mar 2024 at 09:28, Alice Osako wrote:

I don't especially want to step on the toes of Benjamin Kowarsch and his colleagues, but I think it in addition to what I've already done with CardBitOps library, might be worth the trouble to hoist several other elements of the M2BSK library to separate projects, to make it easier to apply them to other projects beyond both M2BSK itself and those I am already working on.

The code is published open source in a public repository precisely so that other people can benefit from it.

 

I don't suggest this lightly, if for no other reason than that it puts me in the position of being the key figure in maintaining several libraries. However, I suspect that others would benefit from doing this.

<snip>

 

I can move the code out into a separate repository and give anyone who wants to contribute write access. This would probably be better than forking it. Also, nobody will then have to worry about taking on responsibility for the repo. People can just contribute on an ad-hoc basis.

    Hoisting these modules to a separate repo en masse would make a
    great deal of sense. Please do so if you if you have the chance.
    Thank you for offering to do so.
    
    I'm not sure if keeping it as an open repo is the best solution, as
    it is more typical in Git projects that each contributor forks the
    project and issues pull requests when ready; while this does require
    an active maintainer, it would ensure that merge conflicts are
    suitably resolved. It also means that the maintainer wouldn't need
    to explicitly allow individual contributors access to the main repo,
    as anyone could fork the project, make their changes, and then issue
    pull requests, which the maintainer could then review for
    suitability.
    
    It also means that individual contributors can have private branches
    of the trunk, for experimental changes and additions, then merge
    them to their local trunk and issue a pull request with just the
    modified trunk, rather than exposing all of the various temporary
    branches. 
    
    Finally, an open repo does run the risk of someone vandalizing the
    repo, though it is unlikely as each contributor would presumably be
    vetted by the maintainer.
    
    Either way, there would still be a need for someone to actively
    maintain the project.
    
    However, this is your choice, and I expect that you already know the
    practicalities of each approach. It should work well enough in any
    case - I don't expect that there would be a lot of concurrent edits
    to merge, nor would I expect anyone to bother trying to vandalize
    the repo.