Re: [PATCH for-next 3/3] test range file alloc

[Eli Schwartz <eschwartz93@gmail.com>]

On 6/30/22 11:18 AM, Pavel Begunkov wrote:
> On 6/30/22 15:31, Ammar Faizi wrote:
>> On 6/30/22 9:19 PM, Pavel Begunkov wrote:
>>> Nobody cared enough to "fix" all tests to use those new codes, most
>>> of the cases just return what they've got, but whatever. Same with
>>> stdout vs stderr.
>>
>> That error code rule was invented since commit:
>>
>>     68103b731c34a9f83c181cb33eb424f46f3dcb94 ("Merge branch
>> 'exitcode-protocol' of ....")
>>
>>     Ref: https://github.com/axboe/liburing/pull/621/files
>>
>> Thanks to Eli who did it. Eli also fixed all tests. Maybe some are still
>> missing, but if we find it, better to fix it.
> 
> Have no idea what you're talking about but I'm having
> hard time calling 6 returns out of 21 in this file "all".


Hi, I should probably clarify the state of affairs...

I submitted a patch series on github 4 days ago which implements those
new codes. It was merged 2 days ago. This is very new code, so I think
it's not completely 100% fair to say that no one "cared" enough to use it.

As far as the actual changes and their completion go... take a look at
the commit messages in the merged patches, specifically take a look at
commit ed430fbeb33367324a039d9cee0fd504bb91e11a.

"""
tests: migrate some tests to use enum-based exit codes

[...]

A partial migration of existing pass/fail values in test sources is
included.
"""

You can also take a look at Github's equivalent of a cover letter, in
which I mentioned that I haven't ported everything, but what I did do is
still useful because "a) it has to start somewhere, b) it demonstrates
the basic idea of how to structure things."

As far as I'm concerned, I believe the patch series stands on its own
merit. I established the framework to use, and that on its own is useful
and deserves merging, because it means that people can start using it,
and getting things correct from the beginning when adding new code.

Old code does need to be carefully checked, it's not a simple
find/replace, but that can be done incrementally, and I'm willing to
continue work on that myself. I just don't think it has to be all or
nothing at the time of merging.


...

Also, for the record -- while waiting for the Github patch series to be
merged, I did continue to convert more code via git commit --fixup= &&
git rebase -i --autosquash. If it had taken longer to end up being
merged, I would have ended up converting more tests over, and that would
have reflected on the current state of git master.

I'm not sad that it got merged when it was, because again, this work can
be done incrementally and people can take advantage of existing work
immediately. Jens decided it was ready to merge, and that seems like a
fine decision to me. If he had asked me to finish porting all the tests
first, I could have done that too.

More will get done in short order. I'm not even a bottleneck for doing
it. :)

(Though I will work on it.)


-- 
Eli Schwartz