[Mingw-w64-public] Wine and mingw-w64 cooperation

[NightStrike]

On Wed, May 22, 2019 at 3:44 PM Jacek Caban <jacek at codeweavers.com> wrote:
>
> Hi all,
>
> [I'm addressing it to both mingw-w64-public and wine-devel]
>
> As most of you know, Wine and mingw-w64 have a lot in common and
> cooperate to some extend for quite a while. There have been talks about
> tightening this relationship for years. Recent Wine move to using PE
> files for its builds led us to revisit those ideas. My feeling so far is
> that there is an agreement among people I heard from that it's a good
> direction for both projects to have mingw-w64 under an umbrella of the
> Wine project.

I've never heard this before, but I would tend to disagree that this
is a good direction.  For some history here, I will highlight that I
am a huge proponent of collaboration.  If you recall, Jacek, it was me
that wandered into your IRC channel over ten years ago now begging for
your help on this project, and it's been a very long (and productive!)
road since then.  Admittedly, my participation has dropped off
considerably given my current occupation, but I pushed hard for the
same collaboration with many other projects: Firefox, ReactOS, Fedora,
Ubuntu, Cygwin, every open source game I could find, even Chromium
(that one didn't work out).  In all cases, we pushed for
collaboration, not takeovers.  A prime example of this is msys2, which
was incubated as a subproject under mingw-w64, but rapidly grew into
its own.

> It would be great to move forward with this. Let me discuss a few
> aspects of the idea.
>
> - Infrastructure
>
> mingw-w64 currently mostly depends heavily on SourceForge. While I'm
> thankful to SF for years of free support, it's doesn't feel like an
> optimal choice those days.

Why not?  SF provides a tremendous amount of service for free, with
impeccable uptime.  There was a point in time where we were uploading
several terabytes a day to the file storage area, for instance.  They
supported this with no issue.  They provide near immediate service via
IRC, and offer a lot of additional capability that we could take
advantage of if we needed to.

> Wine has its own infrastructure that
> mingw-w64 could use right away. Moving things like mailing list, bug
> tracker, etc. is straightforward to do, except for one thing... how
> should it be called? Which brings us to the next item.

What functionality does Wine provide that exceeds what we currently
have that we couldn't take advantage of today?

> - mingw-w64 name
>
> There have been talks about rebranding mingw-w64 for a long time (longer
> than I am in joined the project). While it's a good name for a branch,
> an established project that is no longer related to mingw.org could have
> a better branding. Kai mentioned that ironcrate was considered as some
> point, but to my knowledge no action was taken at that time. Alexandre
> offered lately that Wine brand could be used for mingw-w64 as well. I
> personally like the idea. Wine is already well recognised brand and
> brings roughly right associations. So... how about WineSDK?

Absolutely not.  First, ironcrate was a codename for development
efforts of subprojects within mingw-w64, the largest of which was
winpthreads.  But second, mingw-w64 is a well established brand that
is today significantly more recognizable than the predecessor
mingw.org.  There is a very high cost of changing names, which is why
we haven't done it yet.  I don't see any upside of doing so.

> - Source code sharing
>
> Technically, we could share much more code than we currently do.
> Duplicating efforts is quite suboptimal for everyone. Right now
> mingw-w64 imports a number of platform headers and widl tool from Wine
> via wine-import.sh script. Wine has a few headers imported from
> mingw-w64 as well. It works to some extend, but the fact is that we
> still duplicate more than we share. I'm not yet sure how to fix that
> entirely, but I'd like us to have a workflow that would limit the
> duplication.

This has nothing to do with the stated goals of the email.  We could
share code better today without changing anything.

> - Testing
>
> Wine has a TestBot and a number of test cases, which is a great tool for
> developers to make sure their patches are right. mingw-w64 does not have
> such thing and mostly depends on developers doing their own testing and
> regression reports after the patch is committed. We could integrate
> mingw-w64 testing with Wine TestBot to make sure that we don't break
> things (well, at least limit that possibility). I believe that it would
> nicely accelerate mingw-w64 development workflow as well as ensure that
> mingw-w64+Wine don't regress.

This also has nothing to do with the stated goals of the email.  We
could use the TestBot today without changing anything.  As a concrete
example, we did this for YEARS with the reactOS buildbot until
interest in that waned and ReactOS stopped providing the buildbot
server.  We did daily builds of mingw, gcc, and binutils, and ran the
full testsuite of all of them weekly (natively on windows under
cygwin, the gcc testsuite can take 3 or 4 days).  I was the one who
ran that buildbot, and I kept doing so until the supply of buildbot
slaves dropped off and nobody was particularly interested in the
results anymore.  That is not to chastise the users at all -- our
userbase grew, and large distros like Fedora took on that task of
regular testing, removing the usefulness for maintaining the build
machinery.  Recently, Rainer on GCC has been doing regular testsuite
runs and posting the results to the gcc mailing list.

But in any case, we've in the past had as many as three different
projects doing massive test runs of mingw-w64 in parallel.  That can
easily happen again, today, without any changes.

> - WineConf
>
> The annual Wine conference is a nice chance to meet other contributors
> in person:
> https://wiki.winehq.org/WineConf
> It would be great mingw-w64 developers there as well.

You could easily invite us to this conference without having to
swallow up the whole project.

> Any ideas, comments and thoughts on this topics are welcomed.

Clearly, I think it's a bad idea :)

I will point out that mingw-w64 serves many masters.  While Wine has
become the largest contributor most involved collaborator (and for
that, we should be very grateful), I think this approach toward
project merging will significantly change the focus and purpose of
mingw-w64 and will hamper our ability to support our other customers.
It is my guess that we can collaborate *better* without having to
merge and rename the two projects.