Wayland driver development - December 2021 update and next steps

Zebediah Figura zfigura at codeweavers.com
Fri Dec 10 18:46:46 CST 2021


On 12/10/21 14:30, Paul Gofman wrote:
> On 12/10/21 23:05, Alexandros Frantzis wrote:
>> On Fri, Dec 10, 2021 at 09:44:23PM +0300, Paul Gofman wrote:
>>> Hi Alexandros,
>> Hi Paul,
>>
>> Thanks for the feedback!
>>
>>> On 12/10/21 20:56, Alexandros Frantzis wrote:
>>>> In the mailing list discussions earlier this year it was recommended
>>>> that we go through wine-staging as a stepping stone towards upstream.
>>> Do you recall which part of the prior discussion made such an 
>>> impression?
>>> Staging used to be a testing ground for some patches, yes, but as far 
>>> as I
>>> know no patchset was ever easier to get accepted upstream because of its
>>> presence in Staging. Nor that ever was a requirement for any patches 
>>> to get
>>> upstream. So in this regard it would be probably more interesting to get
>>> some opinion if the direction the things are being implemented now is
>>> acceptable for upstream and Staging probably can't help with that.
>> My understanding was based on a discussion earlier the year, see for
>> example the thread at:
>>
>> https://www.winehq.org/pipermail/wine-devel/2021-February/181667.html
>>
>> Of course, the circumstances have changed since then, and it could be
>> the case that going through wine-staging is not the most productive way
>> forward anymore.
> 
> Yeah, I see... I don't think anything changed. I think it would be best 
> if Zebediah would comment directly but I suppose the meaning of her 
> older comment is that she's not against seeing it in Staging if there is 
> a clear understanding that something along the lines of present 
> implementation can go upstream. Maybe it might be a good way for some 
> riksy patches to get some prior testing before the patches get finalized 
> and go upstream but (correct me please if I am wrong) I don't think 
> upstream maintainers recommended patches to go to Staging first or 
> otherwise indicated that it is a shorter or preferred way for patches to 
> go upstream.
> 
> 

I don't think I'd assert that patches, however large or small, *should* 
go through wine-staging as a "stepping stone" to upstream. I wouldn't 
see wine-staging as an end goal or even a necessary step. I'd rather 
look at it as a tool; essentially a way of getting broad testing. In 
essence, the same reason that staging branches exist in any project.

Thus I'm not sure that the sheer existence of a patch has helped its 
credibility upstream—it might have happened, but I haven't heard of it. 
On the other hand, I can name several patches which have benefited 
greatly from user testing while in wine-staging, such that a lot of bugs 
were flushed out by that time. ntdll-Junction_Points, Rémi's raw input 
patches, Andrew's winepulse timing rework, and my own 
server-default-integrity and ntdll-NtAlertThreadByThreadId are several 
such cases.

I can't speak for Alexandros, but if this is his goal in proposing the 
driver for wine-staging, I don't have any objections, at least on those 
grounds. And, frankly, when we're talking about an entire USER driver, I 
can anticipate that the testing that wine-staging provides would be 
quite useful.

I do have some other thoughts, but I'll have to defer them for a 
separate email.



More information about the wine-devel mailing list