[PATCH 1/2] mshtmlmedia: Add dll.

[Austin English]

On Apr 24, 2022 at 4:38 AM Nikolay Sivov <nsivov at codeweavers.com> wrote:

>
>
> On 4/24/22 11:48, Austin English wrote:
> > On Sat, Apr 23, 2022, 07:17 Nikolay Sivov <nsivov at codeweavers.com>
> wrote:
> >
> >> On 4/23/22 11:57, Mohamad Al-Jaf wrote:
> >>> On Sat, Apr 23, 2022 at 4:01 AM Nikolay Sivov <nsivov at codeweavers.com>
> >> wrote:
> >>>> What I mean is, have you checked that?
> >>> Why would that be necessary? It's clear that the game tries to load
> >>> mshtmlmedia under Windows 7 so why wouldn't this be the case in Wine
> >>> running in Windows 7 mode?
> >> Testing on wine would be necessary to see if it's needed.
> >
> > I have to agree with Mohamad here. AFAIK, it's never been a requirement
> > that a patch actually be verified before committing it:
> >
> > 1) I don't see it mentioned on
> https://wiki.winehq.org/Submitting_Patches
> >
> > 2) There are over a thousand bugs that have been closed fixed that
> contain
> > the comment 'Should be fixed by':
> >
> https://bugs.winehq.org/buglist.cgi?bug_status=CLOSED&limit=0&list_id=762726&longdesc=should%20be%20fixed%20by&longdesc_type=substring&order=bug_id&product=Wine&query_format=advanced&resolution=FIXED
> >
> > (I realize that isn't an accurate count, but demonstrates my broader
> point).
>

---Sorry for preemptive send---

FYI,  I was trying to comment constructively, not aggressively.


> Your point is that there are more CLOSED/FIXED reports that don't have
> "should be fixed by" ? One way to improve this situation was to link bug
> urls in commit messages. We should definitely continue improving it, for
> better traceability.
>

I agree, we should absolutely try to improve commit messages/link bug
reports appropriately.

If you mean that "should be fixed" translates to "I think it might be
> fixed, but I'm not sure", in my experience it usually means the
> opposite, when commenter actually tested it one or another to make sure.
>

Sometimes it does (which is why the overall number isn't accurate), but a
lot of developers also use more definitive phrases like 'this is fixed by
XXXXX'. I also recall several bugs that were commented/closed as 'should be
fixed by ..' and then reopened after testing confirmed it hadn't been
fixed..and for reasons that the author could/should have realized.
Generally for bugs that have phrases like 'this is fixed by XXXXX' don't
have that mistake.


> >
> > If there's constructive feedback that hasn't been given, by all means,
> give
> > it, but "it hasn't been explicitly tested" isn't a reason to block in
> > standard wine development. Maybe we should revisit that, but until we
> do, I
> > don't think it should block this patch.
> >
>
> It depends really. In this case it's some internal IE11 (or maybe a bit
> older) module, with only justification that some users, running actual
> Windows 7 installation, found it useful. Second example is that it was
> mentioned in chromium sources somewhere. Is it unreasonable to discuss
> if it's useful for Wine?
>

No, I think it's absolutely reasonable to question it, to a point. But
given that the codebase shows it's possible, and that there are public
reports showing that it happens is reasonable evidence.

At the same time, I agree of course that just the contributor's desire
> to work on something is enough to consider submitted work. For this
> patch what kind of feedback would you expect?
>

I think the feedback/review, in general, has been fair/valid. I am
disagreeing in how explicit Wine is being, as a project, for testing
patches before submitting upstream.


> P.S. needless to say, my replies are my own, I don't have the power to
> reject submitted work, nor would I like to have it.
>

I agree that _actually_ testing would be ideal, but I don't think it should
be a _blocker_. That said, I'm in the same position, and my position is my
own. I raise it because I feel like few others were giving feedback :).

-- 
-Austin
GPG: 267B CC1F 053F 0749 (expires 2024/02/17)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220424/cd09333c/attachment.htm>