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