[LFM] Looking for maintainer

[adamkewley]

After a few years of mostly only accepting version bump patches and very small changes, I've decided that I don't have the mental energy/space to think about this project right now. In fact, I barely have any bandwidth for personal OSS projects at all (check my account). Therefore, I'd like this repository to be forked over to a new maintainer/organization.

The reason I'd prefer a fork over (e.g.) giving repo access for this repo to the maintainer is because I don't want any unsupervised changes/development happening under my personal account name. With a fork, the maintainer gets full branding and responsibility. With that in mind, I envision the steps being:

• Identify a suitable maintainer. Ideally, someone who's already contributed.
• Ask them to fork the repo
• Add a notice to this repo at the top of the README.md along the lines of THIS IS NO LONGER MAINTAINED GO TO THIS VERSION INSTEAD I TAKE NO RESPONSIBILITY FOR THAT FORK ETC.. Try and tick any boxes with cargo etc. so that automated tools can detect that the repo is out-of-maintenance.
• Archive this repo

[adamkewley]

My first nominee for a new maintainer is @musicinmybrain , if you're up for it?

The reason I nominate you first is because you've been consistent in bumping the upstream libdeflate submodule very soon after ebiggers releases something. I'm guessing you have a project that uses this code. I anticipate that almost all maintenance work will be bumping the C library, which you're already doing as a contributor (although it'll be your fork, so of course you can go and radically change whatever you want).

[musicinmybrain]

I appreciate the vote of confidence, and the honest assessment of your own situation.

My interest in this project has been via maintaining rust-libdeflate-sys and rust-libdeflater packages in Fedora as dependencies for https://github.com/shssoichiro/oxipng (Fedora: rust-oxipng) and https://github.com/milesgranger/cramjam (Fedora: python-cramjam).

I’m happy to keep contributing these libdeflate bumps, but I think that my level of interest probably does not extend to taking actual ownership of the project.

I’m going to reach out to some of the projects, like https://github.com/shssoichiro/oxipng, that rely heavily on this library, and see whether they are interested in becoming involved (or, I suppose, in finding an alternative dependency).

[TPS]

Would it make sense to move ownership & actual location of this repo to a new or existing org (rather than another personal acct) & then setup new admin(s)? This has advantages over forking when it's simply that (a|some) new maintainer(s) wish to take over, not the least of which is that GitHub itself will automatically handle redirects w/o needing to archive this repo & asking the many packages that use this repo to manually update to another (of perhaps multiple) fork(s). This ensures better continuity over the plan proposed originally above.

[adamkewley]

@musicinmybrain thanks for helping the search!

@TPS yes I think that's an excellent point. I wasn't too sure if creating an org is too heavyweight, but if it's just a matter of having a lightweight org as a named shell for the project, then it makes perfect sense to first transfer libdeflater into one and then separately deal with adding maintainers if I can find any willing ~victims~ participants. Doing it that way decouples transferring the repo from finding maintainers, for sure.

So as a first point of action I'll try and create an org for the repo and get it transferred there. I'll keep maintaining (i.e. accepting bump PRs from @musicinmybrain 😄 ) for a while but if a regular contributor finds PRing etc. a bit annoying then I can separately set up maintainers etc.

[adamkewley]

Transferred the repo to https://github.com/libdeflater/libdeflater . Forwarding seems to be working fine.

I'll go through the repo and replace any mention of my name with the org name, where appropriate. Handling the credentials for crates.io is also a concern, but I'm guessing that there is a way of me administering API keys for other users?

[adamkewley]

Just as a note: the changes to Cargo.toml etc. that point to the new org-based URL will be updates on crates.io during the next release, which will probably be whenever libdeflate is bumped. It's not worth creating a patch/tagged release to update that change (esp. when forwarding is available).

[ace-dent]

@adamkewley –

... unsupervised changes/development happening under my personal account name ...

Would you consider a policy of signed commits? This seems increasingly popular, for hardening the audit trail at least.

[adamkewley]

@ace-dent my motivation for LFMing is to have other people (likely, people I don't personally know, but I initially believe are going to keep it up-to-date) maintain the repository. This implies I won't be reviewing or signing off on the commits.

If, by signing, you mean the maintainer (whoever it is) GPG crypto signing the commits, that's an extra step that's really more about verifying that the author field of a particular commit is probably valid (because, for example, anyone call call themselves Linus Torvals but only Linus can use that name and cryptographically sign the commit with his private key) - this is something that's necessary when handling distributed projects without a central authentication server (e.g. not GitHub) but not important in this case.