Maintainer(s) wanted

[djrobstep]

It's been a great experience building migra into a fairly popular project, but recently circumstances have changed and life has moved in new directions.

I don't use Postgres much myself anymore these days, and hence don't use migra. When I was using my own tool regularly it was easy to notice problems, make regular fixes, keep familiar with the code, and enjoy the benefit of my own bugfixes.

Now that's not the case, it's a lot harder to find the time to maintain this project. Issues and PRs are looking neglected and I'm sad that I can't put aside time to give them the attention they deserve.

Thus it seems like a natural time to find a new maintainer (or several), or are better positioned than me to handle issues, PRs, and new features in a timely manner.

There are several fun avenues to take future versions of migra:

• Proper dependency resolution (make a graph of all dependencies and topologically sort it)
• Integration with the diffing capabilities of the latest pgadmin
• Refresh the code to remove py2 cruft and take advantage of new python3 features (such as dataclasses)
• Many others

If you're interested in being a maintainer, please get in touch to discuss.

Ideally you'd be:

• A regular user and familiar with migra
• Have contributed to the project in the past already and be familiar with the code (not keen to add complete strangers as maintainers)
• Have some employer support to work on it
• But not be somebody who is just there to add features you yourself or your employer needs - migra needs to serve lots of different people and issues need to be prioritized fairly
• Be community-minded/friendly/welcoming to newcomers/not a bigot/etc etc

I'll still be around as a maintainer and for general advice/opinions - but hope to take a step back.

Cheers,

Robert.

[seagreen]

I don't use Postgres much myself anymore these days, and hence don't use migra. When I was using my own tool regularly it was easy to notice problems, make regular fixes, keep familiar with the code, and enjoy the benefit of my own bugfixes.

Now that's not the case, it's a lot harder to find the time to maintain this project. Issues and PRs are looking neglected and I'm sad that I can't put aside time to give them the attention they deserve.

Sounds like very solid reasoning.

I don't have the skills to step up as a maintainer, but I just wanted to say thanks for taking this project as far as you did. It saved me a bunch of time and headache over the last year.

[karolzlot]

About this point:

Integration with the diffing capabilities of the latest pgadmin

I tried both. Pgadmin diff takes into account some features which migra doesn't (details), however migra generated SQL seems to be way better, it has correct order and uses ALTER often.

By comparison I couldn't execute diff generated by pgadmin.

Example of some code cut from pgadmin diff (notice that it can't be executed, because things depend on each other):

CREATE SEQUENCE IF NOT EXISTS public.user_id_seq
    INCREMENT 1
    START 1
    MINVALUE 1
    MAXVALUE 2147483647
    CACHE 1
    OWNED BY "user".id;


CREATE TABLE IF NOT EXISTS public."user"
(
    id integer NOT NULL DEFAULT nextval('user_id_seq'::regclass),
    full_name text COLLATE pg_catalog."default",
)

TABLESPACE pg_default;

So I just say big thank you for this tool, nothing like this exists. I just dicovered it but I already want to use it in some of my projects.

[maximsmol]

I just talked with @AidanAbd and @kennyworkman and we'd be interested in taking over migra with the support of our company. We've been using migra on a daily basis since July 2021 and are completely reliant on it, hence the interest in supporting its future development. We're quite small (seed stage startup, currently 3 engineers + 2 more coming in shortly) so we haven't had a chance to make a name for ourselves in the open-source community yet, but we have always intended to contribute extensively to the tools we use as well as publish our internal packages.

Our contributions to OSS so far:

• Contributions to Flyte: rfc: docstring metadata flyteorg/flyte#1856 (implementation merged to master) + Union Types RFCs flyteorg/flyte#1926 (PRs being iterated on)
• Public package release: https://latchbio.substack.com/p/structured-csv
• More on the way with publishing internal libraries, react components etc.

We are ready to commit to maintainer duties (PRs, issues, etc.) and to work on improving the tool over time (including publicity like blog posts etc.). The way we see it, open source work is a very easy way to get credibility with the type of engineers we want to hire so we are going to treat migra as more of a public product than internal tool—broad community interests will be more important than our internal concerns. Still, migra has a direct impact on our bottom line so we will also be directly funding the development.

@djrobstep thoughts on this?

[djrobstep]

Closing this for now, as we have some new maintainers! Plus I'll be continuing involvement with some new plans. Further details to come in an updated readme and contribution guide.