[PATCH resend 1/8] comctl32/listbox: Make SetCount fail if LBS_NODATA is not set

Gabriel Ivăncescu gabrielopcode at gmail.com
Tue Nov 6 05:24:52 CST 2018


On Tue, Nov 6, 2018 at 10:57 AM Nikolay Sivov <nsivov at codeweavers.com> wrote:
>
> On 11/5/18 5:40 PM, Gabriel Ivăncescu wrote:
>
> > On Mon, Nov 5, 2018 at 2:38 PM Nikolay Sivov <nsivov at codeweavers.com> wrote:
> >> What we need first is more tests covering this series and actual
> >> implementation that you have written.
> >>
> > But there will be more patches that I split before I implement
> > LBS_NODATA. And in fact the LBS_NODATA patch is pretty large by itself
> > (mostly due to multi-column listboxes). Do you want me to send them
> > all in one go? (it's about 9 patches or so, the last one is pretty
> > large, couldn't split it up).
> >
> > These patches, for now, don't break anything though, only correct some
> > behavior. LBS_NODATA will still work (but very bad performance).
> > That's why I split them. Are you sure you don't want them as it is?
> > (then I can send the next batch)
>
> No, I don't want them in one go, all I asked is to work to get tests
> committed first, and then proceed with the rest.
>
Would it not be acceptable to have simple patches followed by tests
that are relevant to those patches? Last time, I was told to do it
this way so I wouldn't have to use todo_wine when it ends up being
replaced afterwards.

So I'm conflicted as to what's the actual practice of sending tests
and how it is supposed to be done.

For now I'll send the patch series again but with all relevant tests
after the given patches -- hopefully that's OK with you. So e.g. first
patch fixes something, then it's followed by tests that prove it's
right. Next patch fixes another thing, then it's followed by relevant
tests for it, etc. This way I avoid having to use todo_wine at all and
still prove correct behavior.

The patches are pretty simple before the actual implementation of LBS_NODATA.



More information about the wine-devel mailing list