Project maintainance

[abenhamdine]

Follow up of #104 (comment)

Some background : @xiamx the original author of this module, and @crispmark another contributor, have both left SweetIQ and can't provide maintenance anymore (see #81 (comment)).

At @Arhia (my company), we use this module everyday in a very big application and we would want this project to be maintained, so I proposed to start a fork and ensure a (at least minimal) maintenance.

Contributors will of course be welcomed.

The goal is to maintain the project and merge the potential good PR pending here.

Some questions though :

1. Organization

I created schemats organization today : https://github.com/schemats
I will invite people later (I'm still learning how to manage Collaborators rights)

2. Start point for the fork

Should the repository be forked from here or from https://github.com/xiamx/schemats/ ?
The latter is 12 commits ahead so I would like to start from it, @xiamx can you confirm it's a good idea ?

3. Forking or cloning

Forking keep the link with the original repository, but it's unlikely here that we will be able to merge back into SweetIQ/schemats so I would rather clone the repo, for clarity.

4. Npm

It looks like @xiamx owns npm account (see #104 (comment)) so we would be able to publish new version under the same name, providing a smooth transition.

[HoldYourWaffle]

I'd love to contribute to this new fork!
I think we should compose a list of all useful forks/PR's/issues that should be transferred to the new "fork"/version.

I already have #105 and an implementation of 'lookup tables' as enums pending. While creating these contributions I noticed that the current project structure doesn't have a separate build directory, I'd love to see that changed as well (probably already have a commit for that laying around somewhere).
Also I'd suggest adding dotenv to allow for easier configuration of the POSTGRES_URL and MYSQL_URL environment variables.

Should the repository be forked from here or from https://github.com/xiamx/schemats/ ?
The latter is 12 commits ahead so I would like to start from it, @xiamx can you confirm it's a good idea ?

I get the impression that @xiamx's intended for it to be a new home anyway so that'd probably work.

Forking keep the link with the original repository, but it's unlikely here that we will be able to merge back into SweetIQ/schemats so I would rather clone the repo, for clarity.

Should we change the name if we clone instead of fork to prevent confusion? I think perhaps the best possible solution would be to transfer this repository over to the new organization and go from there. This also makes merging pending material a lot easier.

[abenhamdine]

Should we change the name if we clone instead of fork to prevent confusion?

You're right but all meaningful names (typedschema, etc) are already used, and if we can publish with the same name on npm, it worth keeping the name schemats for consistency.

I think perhaps the best possible solution would be to transfer this repository over to the new organization and go from there. This also makes merging pending material a lot easier.

I don't think @xiamx could easily transfer this repository, it belongs to SweetIQ company (@xiamx can you confirm ?).
If it's the case, we will have to clone or to transfer https://github.com/xiamx/schemats/ to the new organization https://github.com/schemats

[evdhiggins]

2. The https://github.com/xiamx/schemats/ fork is mostly url changes (SweetIQ -> xiamx), build/configuration fixes, and package updates. I think that it definitely makes sense to use that fork as the starting point.

3. Echoing what has already been said, I would agree that cloning makes the most sense. It's a shame that a deprecation + link from the current repo to the new one isn't likely.

4. This is great!

I'm not sure if I would advocate for a renaming of the codebase (as it's still the same tool), but if this was necessary I would recommend a subtle change like schema-ts.

[HoldYourWaffle]

I'm not sure if I would advocate for a renaming of the codebase (as it's still the same tool), but if this was necessary I would recommend a subtle change like schema-ts.

We should probably add a section on what this "new version" is to the README if a namechange is this subtle, to make it clear that this is the new and improved (and maintained) version.

I hope @xiamx can find a way to transfer this repository so we can avoid all confusion and keep the open issues/pull requests. Merging his fork as "starting point" would be trivial.

[xiamx]

Unfortunately I don't think transfer of repo is a possibility. All the people I worked with before from sweetiq no longer work there...

It sucks that there's no easy way to redirect traffic from this project to the new one. But if this new fork/clone fixes important bugs, then recognition and popularity will flow in eventually 😄

[HoldYourWaffle]

That's unfortunate. Of course if we can publish to npm under the same name we can easily change all links to the new organization to direct any new users to the new location. Creating an issue in this repository with a title like "look over here for fixes" would probably be enough to direct all existing users (eventually).

That still leaves the issue of transferring PR's and issues however.

[xiamx]

I've sent an email to github support to see if they have a way to mass copy issues and pull requests to a fork. Let's see if there's a non manual repetitive way available for us.

[jhenson29]

What’s the status of this? I would like to use Schemats in projects, but I was concerned that it looked abandoned. I can assist with maintenance if needed.

[abenhamdine]

What’s the status of this?

I have forket this project to https://github.com/schemats/schemats and I'm loooking how to float the pending PR to the fork.

I would like to use Schemats in projects, but I was concerned that it looked abandoned. I can assist with maintenance if needed.

At @Arhia we will maintain it anyway, we rely on it for a very big application.

[evdhiggins]

In the case that PRs cannot be transferred, what would you anticipate the fallback plan to be? I suppose that any of the larger PRs could be separately forked and merged with the the new repo prior to the full divergence.

To be honest, I would be a bit surprised if there was a non-manual way to transfer issues & PRs.

[abenhamdine]

To be honest, I would be a bit surprised if there was a non-manual way to transfer issues & PRs.

Yes and no.
I will probably be able to recreate PR from the forks via the website.
For simple branches, I will have to use command line
see https://stackoverflow.com/questions/6022302/how-to-apply-unmerged-upstream-pull-requests-from-other-forks-into-my-fork

[HoldYourWaffle]

The command line probably wouldn't be necessary because you can create PR's from other people's forks (unless I'm missing something here...)

[abenhamdine]

The command line probably wouldn't be necessary because you can create PR's from other people's forks (unless I'm missing something here...)

Yes, but only if there's a fork (nevertheless it should be the more common case).
I began to recreate the PR, see https://github.com/schemats/schemats/pull/1

If some folks want to send the PR themselves, they can (but I don't guarantee I will have enough time to review them and merge in the short term)

[xiamx]

If some folks want to send the PR themselves, they can (but I don't guarantee I will have enough time to review them and merge in the short term)

Maybe the folks here (and myself as well) can help contribute reviewing those.

@abenhamdine what's your npm username?