On Wed, May 22, 2019 at 3:44 PM Jacek Caban <jacek(a)codeweavers.com> wrote: 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. 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. What functionality does Wine provide that exceeds what we currently have that we couldn't take advantage of today? 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. This has nothing to do with the stated goals of the email. We could share code better today without changing anything. 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. You could easily invite us to this conference without having to swallow up the whole project. 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.

Hi everyone, I was very excited at first but sadly, it seems this discussion isn't going anywhere. I believe cooperation is always beneficial to both sides so I will try to help moving the debate forward. Jacek listed 5 discussion topics but I think for sake of clarity we should create 5 threads. I will start with the "mingw-w64 name" topic and see how far it'll go. If no one responds, I won't start the other threads. A project name is like a corporation brand, a part of its identity. People associate (project) name to some feelings and events (forks, project leader leaving, takeovers...). For instance, github is now part of Microsoft ecosystem and some people changed their mind after the acquisition. Changing a name may help constructing a new (better) identity. Doing it is a strong signal that tell users things change (new maintainer, new goals...). For instance XBMC -> Kodi told people it became more than an Xbox media player. But if you change the name, you have to improve the project (features, bug handling, test coverage..). Otherwise, some users may feel fooled. I think Jacek idea was just that, if mingw-w64 project is going to change, it may be a good idea to rename it, it was not a Wine takeover attempt. Of course, a name change imply communicating to users so that they take the change into account. Some people are reluctant to this but in fact, it regularly happens (mingw-w64, Kodi, libav project, LibreOffice, MPC-HC, MariaDB...) and if it's justified, people do accept it. So, is there any reason to change mingw-w64 name ? Yes if you want to change the way people see the project and you're ready to change a bit the project. To answer that, you should ask ming-w64 users. What do they like and dislike about the project and what is missing. How do they feel about its name ? I only read Phoronix dedicated thread so it's not really objective but I can't ask users for you. A user <https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1101258-wine-mingw-w64-might-tighten-up-their-relationship-possible-winesdk> finds the name bulky (and the project pretty obscure). Another one <https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1101258-wine-mingw-w64-might-tighten-up-their-relationship-possible-winesdk?p=1101443#post1101443> is confused about the w64 suffix vs Win64. As for the WineSDK proposal, a user explains "[borrowing] Wine branding suggest that it's somehow involved in porting Windows software [...] which is not". I personally agree with him and would suggest mingw-next or mingw-ng to keep the well-known prefix while adding novelty. I don't like the SDK suffix as mingw-w64 is not a sofware development kit. If you decide to change the name, the next step is to decide what could be done to improve the project (will be covered by the 4 remaining discussion topic).

On 22/05/2019 21:45, Jacek Caban wrote: Based on feedback I received (both in this thread and in private channels), it's clear that it's not what community wants. I think there was a lot of confusion, mostly based on false assumption that name change implies other changes. Anyway, keeping mingw-64 name is the easiest thing to do and that's fine with me. If anyone wants to follow up on the name, feel free. I think one idea I received that seems worth mentioning in public is maxgw. I will follow up in other replies on other threads. Thanks, Jacek

On 22/05/2019 21:45, Jacek Caban wrote: Here is how I imagine TestBot could look do: 1. Accept mingw-w64 patches (like it currently does for Wine patches) 2. Build a compiler toolchain This is scripted in many places, so it shouldn't be too hard to automate. We could probably start with the most common configuration. 3. Build a few projects - to make sure they build. Wine, Wine Gecko, VLC should give a good coverage. Francois, how does that sound? Ideally, mingw-w64 would have its own test suite that we could run here as well in addition to the above. Thanks, Jacek