Moving libpng/contrib/ to its own repository
Cosmin Truta <[email protected]> Thu, 26 Feb 2026 01:01:45 +0200
| Newsgroups | gmane.comp.graphics.png.devel |
|---|---|
| Message-ID | <CAAoVtZzwaaNJ-ScXGrFvuxJuHRQydwnjNq53QCr9sooXxHH9_A@mail.gmail.com> |
--===============0094541216596645830== Content-Type: multipart/alternative; boundary="000000000000a5ee84064badfdb3" --000000000000a5ee84064badfdb3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 the 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 Pytho= n - *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 ha= ve 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 =F0=9F=A5=B3 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 --000000000000a5ee84064badfdb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">TL/DR:<br><br>Check out <a href=3D"https://github.com/pngg= roup/pngcontrib">https://github.com/pnggroup/pngcontrib</a><br><br>*****<br= ><br>Hi there, hello!<br><br>I've been considering the creation of a ne= w repository, pnggroup/pngcontrib, to house the auxiliary material that cur= rently lives in contrib/ (and not only!) even though I never got to actuall= y do it.<br><br>I'm doing it now.<br><br>In fact, I did not have it in = my plans to do it for the libpng16 branch, but rather postpone it for the r= elease of libpng18. And yet, here we are.<br><br>I'd like to hear your = thoughts before proceeding.<br><br><b>BACKGROUND<br></b><br>Currently, the = contrib/ directory in libpng contains 16 subdirectories serving very differ= ent roles: the core test suite, SIMD runtime detection fragments, fuzzing h= arnesses, standalone tools, and historical example programs. Some of this m= aterial is tightly coupled to the library. Others are self-contained.<br><b= r>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. O= ne PR (fixing sample code from a 1999 book) has been open since 2018. Meanw= hile, we've had 8 CVEs in 4 months in the core library. Every PR that t= argets auxiliary code competes for review bandwidth with security and corre= ctness work.<br><br>Moving the auxiliary material to its own repository wou= ld not only reduce the noise in the core library's pull request queue, = but also set clearer expectations for contributors about what's activel= y maintained vs. what isn't.<br><br>Moreover, these auxiliary tools sho= uld be allowed to evolve independently, without requiring core library revi= ew cycles. We already have pngcheck and pngcrush right here (at <a href=3D"= https://github.com/pnggroup/pngcheck">https://github.com/pnggroup/pngcheck<= /a> and <a href=3D"https://github.com/pnggroup/pngcrush">https://github.com= /pnggroup/pngcrush</a>, respectively) and we'll add yet more as we go. = The material in contrib/ ranges from sophisticated and useful tools in thei= r own right (like pngcp or gregbook or the pngminus suite) to one-off utili= ties (like checksum-icc and png-fix-itxt). All of it deserves its own space= to evolve.<br><br><b>WHAT WOULD MOVE<br></b><ul><li>=C2=A0 =C2=A0 <b>gregb= ook:</b> Sample code from "PNG: The Definitive Guide" (1999)</li>= <li>=C2=A0 =C2=A0 <b>visupng:</b> Windows PNG viewer</li><li>=C2=A0 =C2=A0 = <b>examples:</b> API usage examples for application developers</li><li>=C2= =A0 =C2=A0 <b>pngminus:</b> Standalone PNG/PNM converters</li><li>=C2=A0 = =C2=A0 <b>pngexif:</b> A standalone PNG-EXIF inspection tool, written in Py= thon</li><li>=C2=A0 =C2=A0 <b>tools:</b> pngfix, png-fix-itxt, pngcp, genpn= g, makesRGB, etc.</li></ul><br>Note on <b>tools</b>: 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, an= d quite possibly a readjustment in the work of downstream packagers who bun= dle these tools.<br><br><b>WHAT WOULD STAY<br></b><br>Everything that is ti= ghtly coupled to the library or actively maintained as part of its developm= ent workflow:<ul><li><b>libtests</b>, <b>pngsuite</b>,<b> testpngs</b>: the= core test suite and test data</li><li><b>oss-fuzz</b>: actively maintained= fuzz testing infrastructure</li><li><b>conftest</b>, <b>pngminim</b>: buil= d configuration testing, tightly coupled to pnglibconf</li><li><b>arm-neon<= /b>, <b>mips-mmi</b>, <b>mips-msa</b>, <b>powerpc-vsx</b>: SIMD runtime det= ection fragments, compiled as part of the library (which shouldn't have= been stored in contrib/ to begin with...)</li></ul><br><b>EXTRACTION METHO= D<br></b><br>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, ori= ginal authorship and commit messages and everything). All preserved =F0=9F= =A5=B3<br><br>See <a href=3D"https://github.com/pnggroup/pngcontrib">https:= //github.com/pnggroup/pngcontrib</a><br><br>Naturally, the original history= of contrib/ shall remain in the libpng repository, permanently.<br><div><b= r></div><div>*****</div><div><br></div><b>OPEN QUESTIONS<br></b><br>Everyon= e,<br><br>In my mind, this lies somewhere between "no big deal" a= nd "ho-hum but it's actually useful", although I admit I don&= #39;t really know about the degree of the inconvenience this might cause to= downstream packagers.<br><br>Are there directories in the "move"= list that you think should stay, or vice-versa?<br><br>For downstream pack= agers: does the removal of pngfix and png-fix-itxt from the libpng build ca= use problems that a separate pngcontrib repository wouldn't solve?<br><= br>If you have any of these concerns (or others) please let me know!<br><br= >Sincerely,<br>Cosmin</div> --000000000000a5ee84064badfdb3-- --===============0094541216596645830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0094541216596645830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ png-mng-implement mailing list png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/png-mng-implement --===============0094541216596645830==--