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

[Jacek Caban]

On 5/23/19 11:52 AM, NightStrike wrote:
> 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.


I wouldn't want to accidentally put words into someone else's mouth, I'd 
rather have interested parties speak for themselves, but for sake of 
transparency let me give you a quick summary. The idea of having 
mingw-w64 under Wine umbrella came from Kai in our private conversation 
a few years ago. Nothing happened until a few weeks ago when I mentioned 
that to Alexandre, who also thought it's worth talking about, and we 
reached Kai. We exchanged a few e-mails and contacted a few other 
contributors to get a sense of opinions. My apologies for not including 
you in that conversation, I haven't seen you around for years. 
Ultimately no decision was made and I think this should be discussed in 
public before doing any step. That's the purpose of my e-mail. I 
wouldn't call it takeover but rather discussing ideas.


> 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.


What takeover are you talking about? Merge maybe, if desired. 
Collaboration, definitely. And I really don't see how proposed changes 
would have negative effect on other projects. Why would msys2 (or other 
projects) be in any different situation than it is now?


>> 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.


That's not the experience I had, but for the most notable thing see 
controversies paragraph:

https://en.wikipedia.org/wiki/SourceForge


>> 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?


Flexibility? Customization?


>> - 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.


Noted. I won't pursue it if that's a common sense. Is it?


>> - 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.


I'm not sure I follow... I just stated it as one of goals of this email. 
Current solution is suboptimal and rather bare minimum. If we can come 
out with a better solution, great. Are you even familiar with how it's 
done today? Some technical changes would be nice. Potential name change 
is obviously not relevant.


>> - 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.


We could probably do it without other changes, yes. If we end up doing 
just that, it's okay. But again I feel like we're thinking of 'stated 
goals' differently.


> 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.


It was never part of the workflow, that's the main problem. It was great 
for bug reports after-the-fact, but it didn't avoid regressions in the 
first place. I believe we could do better.


>> - 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.


To be clear, please feel invited regardless of how this thread ends up.


>> 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.


FWIW, I feel misunderstood and misinterpreted by you. I want the best 
for the project I spent so much efforts on. If you have different 
opinions, that's fine, but please don't make me a swallower of the project.


Jacek