Moving libpng/contrib/ to its own repository

[ctruta]

TL/DR:

Check out https://github.com/pnggroup/pngcontrib

---

Hi there, hello!

I've been considering the creation of a new repository, pnggroup/pngcontrib, to house the auxiliary material that currently lives in contrib/ (and not only!) even though I never got to actually do it.

I'm doing it now.

In fact, I did not have it in my plans to do it for libpng16 branch, but rather postpone it for the release of libpng18. And yet, here we are.

I'd like to hear your thoughts before proceeding.

BACKGROUND

Currently, the contrib/ directory in libpng contains 16 subdirectories serving very different roles: the core test suite, SIMD runtime detection fragments, fuzzing harnesses, standalone tools, and historical example programs. Some of this material is tightly coupled to the library. Others are self-contained.

The problem is visibility. At the time of writing, many of the open pull requests on this repository target contrib/ code that is not the library. One PR (fixing sample code from a 1999 book) has been open since 2018. Meanwhile, we've had 8 CVEs in 4 months in the core library. Every PR that targets auxiliary code competes for review bandwidth with security and correctness work.

Moving the auxiliary material to its own repository would not only reduce the noise in the core library's pull request queue, but also set clearer expectations for contributors about what's actively maintained vs. what isn't.

Moreover, these auxiliary tools should be allowed to evolve independently, without requiring core library review cycles. We already have pngcheck and pngcrush right here (at https://github.com/pnggroup/pngcheck and https://github.com/pnggroup/pngcrush, respectively) and we'll add yet more as we go. The material in contrib/ ranges from sophisticated and useful tools in their own right (like pngcp or gregbook or the pngminus suite) to one-off utilities (like checksum-icc and png-fix-itxt). All of it deserves its own space to evolve.

WHAT WOULD MOVE

• gregbook/: Sample code from "PNG: The Definitive Guide" (1999)
• visupng/: Windows PNG viewer
• examples/: API usage examples for application developers
• pngminus/: Standalone PNG/PNM converters
• pngexif/: A standalone PNG-EXIF inspection tool, written in Python
• tools/: pngfix, png-fix-itxt, pngcp, genpng, makesRGB, etc.

Note on tools/: pngfix, png-fix-itxt, and pngcp are currently built and/or installed by the libpng build system, but none are tested. Their removal would require a build system cleanup, and quite possibly a readjustment in the work of downstream packagers who bundle these tools.

WHAT WOULD STAY

Everything that is tightly coupled to the library or actively maintained as part of its development workflow:

• libtests/, pngsuite/, testpngs/: the core test suite and test data
• oss-fuzz/: actively maintained fuzz testing infrastructure
• conftest/, pngminim/: build configuration testing, tightly coupled to pnglibconf
• arm-neon/, mips-mmi/, mips-msa/, powerpc-vsx/: SIMD runtime detection fragments, compiled as part of the library (which shouldn't have been stored in contrib/ to begin with...)

EXTRACTION METHOD

It's done! By the means of git filter-repo, we now have a brand new repository in which the relevant commit history (311 commits, original authorship and commit messages and everything). All preserved 🥳

See https://github.com/pnggroup/pngcontrib

Naturally, the original history of contrib/ shall remain in the libpng repository, permanently.

---

OPEN QUESTIONS

Everyone,

In my mind, this lies somewhere between "no big deal" and "ho-hum but it's actually useful", although I admit I don't really know about the degree of the inconvenience this might cause to downstream packagers.

Are there directories in the "move" list that you think should stay, or vice versa?

For downstream packagers: does the removal of pngfix and png-fix-itxt from the libpng build cause problems that a separate pngcontrib repository wouldn't solve?

If you have any of these concerns (or others) please let me know!

---

Sincerely,
Cosmin

[LegalizeAdulthood]

I think that's a good split: keep the tests and stuff related to the core library and split off everything else.

You can use gh issue transfer to move contrib related issues from this repo to the new repo.