Project continuity planning

[EliotJones]

Looking to gather thoughts on how best to ensure I'm not the critical blocker on further changes to this library.

Unfortunately a temporary burnout with PdfPig seems to be more or less permanent and I'd like to ensure the library is able to continue to evolve without my input. (this burnout is unrelated to money, this isn't a request for payment, I just need more time which unfortunately currency can't buy)

Obviously the risk of supply chain attacks makes this difficult. The recent XZ Utils attack shows there's a large risk in broadening contributor permissions for a project, even one which is only mildly successful.

Some approaches could be:

• Give full access to merge code and publish releases to a natural successor (thanks @BobLd for your hard work, you're an obvious candidate but would you even want to do this?)
• See if someone like the Apache foundation would want to take it, this feels a bit like a graveyard for projects in my mind, but maybe an unfair view.
• Give access to approve to a second maintainer so that there's more than 1 possible reviewer for each PR, not really sure who would be able to do this.
• Something like Codeshelter or whatever, these orgs that have sprung up for this style of thing, any views of or experiences with these orgs?

Interested to hear thoughts of those involved or who have done this before.

[BobLd]

Hi @EliotJones, I'd be more than happy to take over if you are fine with it. I do agree 100% with you regarding the "XZ Utils attack" risk, but I don't have a proper solution to mitigate that.

I'm also happy to lay down here some next devs I'd like to see implemented in the library if that's of any help.

Feel free to ask anything if you have questions, and thanks a lot for starting this great project!

[iamcarbon]

Hi @BobLd @EliotJones I'm also always happy to provide a second set of eyes for any future reviews.

[EliotJones]

Hi @BobLd, thanks very much. I have decided on the following course of action:

• I have published version 0.1.9
• I have noted in the release notes that this is the last version with me as sole maintainer so that consumers can decide what they want to do with this information (e.g. continue as usual, apply additional auditing to future upgrades, stick to a specific version)
• I have upgraded you to maintainer and add @iamcarbon to write access (thanks!)
• I have emailed you about granting access to push new NuGet versions, this was an email address I had from many years ago so feel free to email me with a better contact address if needed. Once you confirm by email and here I'll add that email to the NuGet package.

[BobLd]

@EliotJones thanks a lot for everything again! I got back to you via email.

[svengeance]

Thanks @BobLd for stepping up and offering a hand. Even if it's just routine dependency updates, having someone around and able to respond is huge.

I wish I could offer real support, but my low-level experience with PDFs is insufficient. The only thing I might be able to help with is perhaps is streamlining the release process, so if that ever gets into your focus with an issue, feel free to tag me on it!

[BobLd]

@svengeance thanks a lot for the help offer, much appreciated. I'm planning to work on the release process shortly (hopefully before end of year). I'll for sure tag you. In the meantime, do you have example of github pipeline you have setup that are publically available?

[svengeance]

I ironically have a basic C# wrapper around QPDF that I maintain/published on NuGet and GitHub.

My process is pretty simple. Every PR has a corresponding update to the RELEASE_NOTES.md file in the root of the repo. When I want to release a new version, my pipeline does a sparse checkout of just that file, and then uses release-action to create a GH release and embed the file into the body of the release notes. In my opinion it's easier to accrue changes in a single file over time than to wait until the release to try to understand everything that happened. The file also gives you more flexibility than you could by building up release notes via commit messages or PR titles, where it's hard to convey multiple enhancements, notes, comments, and breaking changes. This release process also takes care of updating its NuGet packages of course.

If I were to do it a little differently, I might also create a prepend-only file (CHANGELOG.md) in the root of the repo that is updated on-release so users have an at-a-glance file to track changes.

The process of gradual release notes accrual might be beneficial here where contributions are more likely, and it can be added to the contribution guidelines that adequate updates to the file need to be made to describe the change.

[Greybird]

@BobLd, just in case, the nighly release failed to push to nuget, claiming credentials are not working anymore, might be linked to the transition?

Pushing PdfPig.0.1.10-alpha-20241018-ea95a.nupkg to 'https://www.nuget.org/api/v2/package'...
   PUT https://www.nuget.org/api/v2/package/
   Forbidden https://www.nuget.org/api/v2/package/ 1024ms
 error: Response status code does not indicate success: 403 (The specified API key is invalid, has expired, or does not have permission to access the specified package.).

[BobLd]

@Greybird thanks for flagging - should be good now

@svengeance thanks a lot for the details, I'll definitely look into your project. We might use a similar approach to what you did - thx again!