Message ID | cover.1723095269.git.ps@pks.im (mailing list archive) |
---|---|
Headers | show |
Series | Introduce clar testing framework | expand |
On 2024.08.08 07:38, Patrick Steinhardt wrote: > Hi, > > this is the third version of my RFC patch series that introduces the > clar testing framework into our unit tests. The intent is to not have to > hand-craft all features of a proper unit testing framework, while still > not painting us into a corner. As such, the clar itself is small and > extensible while still bringing some nice features to the table. > > Changes compared to v2: > > - Fix a copy/paste error for the clar license. It's ISC, not LGPL. > > - Include "clar.h" via "clar/clar.h" such that we do not have to add > "clar/" as in preprocessor include directive. > > - Adapt strvec unit test to use `cl_assert_equal_i()` instead of > `cl_assert()`. > > Thanks! > > Patrick > > Patrick Steinhardt (7): > t: do not pass GIT_TEST_OPTS to unit tests with prove > t: import the clar unit testing framework > t/clar: fix whitespace errors > t/clar: fix compatibility with NonStop > Makefile: wire up the clar unit testing framework > t/unit-tests: convert strvec tests to use clar > t/unit-tests: convert ctype tests to use clar I'm generally in favor of this change, but I'm still unsure what our plan is for importing this from upstream clar. Are we going to vendor our own copy here and (hopefully) someone will pay attention to upstream fixes and apply them to our copy? Or will we replace this with a submodule?
On Monday, August 12, 2024 2:11 PM, Josh Steadmon wrote: >On 2024.08.08 07:38, Patrick Steinhardt wrote: >> Hi, >> >> this is the third version of my RFC patch series that introduces the >> clar testing framework into our unit tests. The intent is to not have >> to hand-craft all features of a proper unit testing framework, while >> still not painting us into a corner. As such, the clar itself is small >> and extensible while still bringing some nice features to the table. >> >> Changes compared to v2: >> >> - Fix a copy/paste error for the clar license. It's ISC, not LGPL. >> >> - Include "clar.h" via "clar/clar.h" such that we do not have to add >> "clar/" as in preprocessor include directive. >> >> - Adapt strvec unit test to use `cl_assert_equal_i()` instead of >> `cl_assert()`. >> >> Thanks! >> >> Patrick >> >> Patrick Steinhardt (7): >> t: do not pass GIT_TEST_OPTS to unit tests with prove >> t: import the clar unit testing framework >> t/clar: fix whitespace errors >> t/clar: fix compatibility with NonStop >> Makefile: wire up the clar unit testing framework >> t/unit-tests: convert strvec tests to use clar >> t/unit-tests: convert ctype tests to use clar > >I'm generally in favor of this change, but I'm still unsure what our plan is for >importing this from upstream clar. Are we going to vendor our own copy here and >(hopefully) someone will pay attention to upstream fixes and apply them to our >copy? Or will we replace this with a submodule? I think we have our own copy of clar, customized to integrate with the existing make infrastructure.
Josh Steadmon <steadmon@google.com> writes: > I'm generally in favor of this change, but I'm still unsure what our > plan is for importing this from upstream clar. Are we going to vendor > our own copy here and (hopefully) someone will pay attention to upstream > fixes and apply them to our copy? Or will we replace this with a > submodule? As long as we do not have to make any changes to the "vendored" code ourselves, that would not matter. We will not randomly update the gitlink that specifies "we want to use _this_ version and not other version of upstream clar" without good reasons if you are using it as a submodule, and we would need to justify why we are updating the hierarchy if we import the hierarchy as vendored source. So the hassle of "updating from upstream" is pretty much the same. For something as small as "clar", I think it is fine to start with the currently proposed layout and see what happens. If we can keep going without touching the imported part of the sources at all, and the system proves to be useful and stable, that is a good time to suggest moving it out and binding the selected version of the upstream as a submodule. Thanks.
On Monday, August 12, 2024 4:50 PM, Junio C Hamano wrote: >Josh Steadmon <steadmon@google.com> writes: > >> I'm generally in favor of this change, but I'm still unsure what our >> plan is for importing this from upstream clar. Are we going to vendor >> our own copy here and (hopefully) someone will pay attention to >> upstream fixes and apply them to our copy? Or will we replace this >> with a submodule? > >As long as we do not have to make any changes to the "vendored" code ourselves, >that would not matter. We will not randomly update the gitlink that specifies "we >want to use _this_ version and not other version of upstream clar" without good >reasons if you are using it as a submodule, and we would need to justify why we >are updating the hierarchy if we import the hierarchy as vendored source. So the >hassle of "updating from upstream" is pretty much the same. > >For something as small as "clar", I think it is fine to start with the currently proposed >layout and see what happens. If we can keep going without touching the imported >part of the sources at all, and the system proves to be useful and stable, that is a >good time to suggest moving it out and binding the selected version of the >upstream as a submodule. I think we already have a copy customized for git's use. The main clar repo on its own has portability issues. I have contributed a few fixes, but they need work.
<rsbecker@nexbridge.com> writes: >>For something as small as "clar", I think it is fine to start with the currently proposed >>layout and see what happens. If we can keep going without touching the imported >>part of the sources at all, and the system proves to be useful and stable, that is a >>good time to suggest moving it out and binding the selected version of the >>upstream as a submodule. > > I think we already have a copy customized for git's use. The main clar repo on its own > has portability issues. I have contributed a few fixes, but they need work. Yup, but as long as the changes we make are all upstreamable, the story does not change all that much. Changes like "#ifdef TANDEM" would be totally uncontroversial thing for them to accept and we should be able to upstream them fairly easily, and once we thin our local customization down to zero, we'd reach the state I outlined. Starting out with a local copy helps us making these portability and other changes without much friction, regardless of how responsive the upstream is, and the request upstream would see is "here are the changes to make it available on more platforms and/or making it generally more useful. all of these changes have been used and battle-tested in the context of the Git project for N months, please apply."
On Mon, Aug 12, 2024 at 03:13:39PM -0700, Junio C Hamano wrote: > <rsbecker@nexbridge.com> writes: > > >>For something as small as "clar", I think it is fine to start with the currently proposed > >>layout and see what happens. If we can keep going without touching the imported > >>part of the sources at all, and the system proves to be useful and stable, that is a > >>good time to suggest moving it out and binding the selected version of the > >>upstream as a submodule. > > > > I think we already have a copy customized for git's use. The main clar repo on its own > > has portability issues. I have contributed a few fixes, but they need work. > > Yup, but as long as the changes we make are all upstreamable, the > story does not change all that much. Changes like "#ifdef TANDEM" > would be totally uncontroversial thing for them to accept and we > should be able to upstream them fairly easily, and once we thin our > local customization down to zero, we'd reach the state I outlined. > > Starting out with a local copy helps us making these portability and > other changes without much friction, regardless of how responsive > the upstream is, and the request upstream would see is "here are the > changes to make it available on more platforms and/or making it > generally more useful. all of these changes have been used and > battle-tested in the context of the Git project for N months, please > apply." Yeah, agreed. My intention certainly is to upstream all required changes. Right now, it's only two minor fixes that we need, one for NonStop and one for whitespace fixes. While I'm still one of the maintainers of the clar, I first want to connect with Ed before merging any of these fixes. I would otherwise consider it a bit overreaching to just go in and merge things after having been absent from that project for such a long time. But when things are sorted out I think the upstreaming process should be easy enough. Meanwhile, I think keeping this in the tree is fine. We can then optionally convert the code to a submodule once the necessary changes are upstream. Patrick