[RFC] Announcing Wayland driver development

[Julian Rüger]

Hi Alexandros,

first of all, congratulations and thanks for your work, this sounds very
cool!

Disclaimer:

I'm little more than a curious observer of the larger developments in
Wine, but I've been around for a while and have picked up a few things.
Still, you should probably take anything someone who actually
understands the code says over my ramblings ;)


> My first question to the Wine community is how complete the driver
> should be before being considered for inclusion. Is the current Wayland
> driver state enough?

The most important and probably trickiest order of business is to
convince Alexandre you're going the "Right Way" (tm), from an
architectural standpoint.
I can't really say if your current progress is enough to gauge that, but
I think it is.

> If there is interest, I was hoping to get the
> driver in earlier rather than later, in an experimental capacity, in
> order to provide a single, official point of development for people
> wanting to contribute.

You should talk to our tireless and competent staging developers,
Zebediah Figura and Alistair Leslie-Hughes about that.

> My second question is about the best way to move forward with
> upstreaming. The code is currently split between just a few commits,
> mostly as a result of the experimental nature of this effort, and also
> because I used existing code from winex11 and wineandroid as my starting
> point. I would like to split this into smaller commits to make it more
> review-friendly for the mailing list. I was thinking of splitting by
> user32 function (and internal dependencies), but since this is going to
> be an artificial split, I am open to other ideas to make reviewers'
> lives easier.

Again, I'm no expert, but from what I've seen, a good approach would be
to start with a stubbed skeleton driver and build it up from that, piece
by piece, in small logical steps.

The rules for commits are basically:
* leave wine in a consistent and working state after every commit!
* don't introduce dead code
* have meaningful commit messages

(* normally tests are very important, though I'm not sure how much that
applies in this case or how to go about failing tests under your driver)

Read the wiki for more info, notably
https://wiki.winehq.org/Submitting_Patches
and most of https://wiki.winehq.org/Wine_Developer%27s_Guide
though some stuff may be out of date.

FWIW, I recommend looking at the commit history, how past big changes
were introduced i.e. the Mac driver, maybe the DIB-Engine (although that
was quite long ago and a lot has changed since)

Better wait for advice from actual developers here ;)

> Looking forward to your feedback and questions!

I hope that helps a bit, and that when the experts ship in they don't
have to repeat the basics.

This is about all I know, sorry I can't really be more specific. Please
correct anything I got wrong!


Best,
Julian