[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Wayland driver - December 2022 update
From:       Alexandros Frantzis <alexandros.frantzis () collabora ! com>
Date:       2022-12-16 12:20:55
Message-ID: Y5xip0fVhw5jJeY6 () debian
[Download RAW message or body]

On Fri, Dec 16, 2022 at 08:44:05AM +0100, Rémi Bernon wrote:
> Hi Alexandros!

Hi Rémi!

<snip>
> > Next steps:
> > 
> > Last year, due to the extensive ongoing internal rework in Wine (e.g.,
> > win32u), the decision was made to postpone the upstreaming of the
> > Wayland driver until some amount of internal stability had been reached.
> > My impression is that things are a lot more stable now, from the
> > drivers' point of view at least. Is there any upcoming work that people
> > feel would be severely hindered by the upstreaming of the Wayland
> > driver?
> > 
> 
> Probably not as large as this year's refactoring in any case. Ofc, any user
> driver refactoring (and I can think already of a couple of things I'd like
> to see) is hindered by additional driver implementations, but I think it
> shouldn't be a blocker either.

FWIW, I am happy to get involved whenever a core change requires
non-trivial driver updates (see also my comment at the end about
maintainership).

> > Ideally, I would like to start the upstreaming effort (which I expect
> > will take some time) at some point early next year, after the codebase
> > has been unfrozen. Does this sound reasonable?
> > 
> 
> I'm only giving my opinion here, I'd suggest to try and see how it goes.
> 
> Note that IMHO you'd probably be better with someone willing and dedicated
> to reviewing the changes, rather than hope that review will happen by chance
> or by the maintainer.

I would certainly appreciate having a dedicated reviewer (or reviewers).
I know that people's time is both limited and precious, so I would like
to make the process as easy as possible for them.

The driver commit structure, containing generally small and focused
commits, was designed with this goal in mind. The trade-off is that the
driver proposal has ended up with a lot of commits. The idea is to
iteratively propose the first of the remaining commits from the driver
that logically belong together, discuss/update/merge and continue like
this with the next commits/MR, until the whole driver is upstream.

I expect the process will take some time, that's why I would like to
start early, but that's fine. The goal is to ensure that people are
happy with and confident in what ends upstream, and I hope to learn more
myself. Hopefully this process will allow people to become more familiar
with Wayland, too.

If anyone reading this is interested in reviewing when the time comes,
please let me know :)

> In the same way, it would also probably help if you are ready to assume
> maintainership of the module from the beginning, or if someone (else than
> the Wine maintainer) is.

My intention is to keep on working on and maintaining the driver. In
fact, I expect I won't be alone, as this year our "Wayland driver" team
gained two more people, who will be able to help going forward, too.

Thanks,
Alexandros


[prev in list] [next in list] [prev in thread] [next in thread]