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.
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. 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.
- 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?
- 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.
- 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.
- 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.
Any ideas, comments and thoughts on this topics are welcomed.
Thanks, Jacek
All this probably is a great idea :). I just have (entirely worthless) 2c two share on one point you bring up:
Op wo 22 mei 2019 om 21:44 schreef Jacek Caban jacek@codeweavers.com:
- 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?
The thing is, "mingw" is also a "recognized name". Not only as what it stands for (minimalistic gnu for windows, although I never understood that name to describe a windows API implementation...), but also as a toolchain *target*.
Technically, a lot of things are named to match "mingw" (GCC and Clang target names, for example). It has even grown out to its own frankenstein ABI of sorts, next to the MSVC ABI on Windows.
The suggestion to name it WineSDK (very close to WinSDK, clever that ;-) ) seems like a missed oportunity: it would seem to tie the purpose of "mingw-w64" to Wine, which (for me, and a lot of other people) not the primary goal of this project. That goal is providing an "implementation" of the Windows API such that one can generate code that runs on Windows without proprietary tools. The fact that there is a lot of code shared with Wine or where it's hosted doesn't change that, IMHO.
I have no say in any of this (nor do I want to push my opinion), so you can see this as an interested user's comment. Just try to not confuse people even more about what this project is supposed to be.
Cheers and keep up the incredible work!
Ruben
Hi Ruben,
On 22/05/2019 22:17, Ruben Van Boxem wrote:
All this probably is a great idea :). I just have (entirely worthless) 2c two share on one point you bring up:
Thanks for sharing the opinion, it's definitely not worthless ;)
Op wo 22 mei 2019 om 21:44 schreef Jacek Caban jacek@codeweavers.com:
- 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?
The thing is, "mingw" is also a "recognized name".
Agreed, mingw (as in just mingw, replacing the original project) would be my first choice actually. The problem is that we can't use that without mingw.org authors' approval and I don't expect it coming (even using mingw-w64 could be considered controversial without approval).
Name similarity does not help users either, see recent case in mingw.org ML for an example:
https://osdn.net/projects/mingw/lists/archive/users/2019-May/000295.html
Not only as what it stands for (minimalistic gnu for windows, although I never understood that name to describe a windows API implementation...), but also as a toolchain *target*.
Technically, a lot of things are named to match "mingw" (GCC and Clang target names, for example). It has even grown out to its own frankenstein ABI of sorts, next to the MSVC ABI on Windows.
Yes, compiler triplets need to stay as they are, at least for foreseeable future.
The suggestion to name it WineSDK (very close to WinSDK, clever that ;-) ) seems like a missed oportunity: it would seem to tie the purpose of "mingw-w64" to Wine, which (for me, and a lot of other people) not the primary goal of this project. That goal is providing an "implementation" of the Windows API such that one can generate code that runs on Windows without proprietary tools. The fact that there is a lot of code shared with Wine or where it's hosted doesn't change that, IMHO.
That's a fair concern. Explaining such confusion seems easier than promoting a fresh new name. Of course keeping the existing name is even easier if that's the consensus.
Also, Wine is called a compatibility layer. You may think of mingw-w64 as a compatibility layer as well: it provides Windows compatibility to compiler toolchain ;)
Thanks,
Jacek
How about TeaSDK, CoffeeSDK, or GrapeSDK? :p
Not entirely serious, but also not entirely kidding. Grape sounds like a good candidate as a common umbrella for Wine and related projects, since Wine is generated from Grape. Also grape is a simple English word that any primary school student should know well. Last but not least "GrapeSDK" in google search shows no conflicts. I couldn't make up a strong connection between Grape and MinGW-w64 though, maybe other people can jump in and support?
For TeaSDK and CoffeeSDK, maybe they are less relevant, but it wouldn't hurt to have competition ideas ^^
BTW, in 2016 I (and many people's help) built a CI environment to support building both Win32/Linux programs on the same server with uniform usage and configuration without Windows License. The Win32 support was implemented using Wine with Cygwin/MSYS2 support, and I decided to call the CI server TeaCI: https://docs.tea-ci.org/usage/overview/ (Lack of maintenance, stop working these days, shame on me)
Thank you for this great idea. I agree with the cooperation. But I have some questions and concerns.
1. What will happen to all the mails, patches, users contributions, issues, releases etc.? 2. Where should we now send the emails and patches? I would suggest for a separate mailing list. 3. Will all the coding practices, restrictions (e.g. c89) of wine repository also apply to mingw-w64 repo? 4. What will happen to the other dependent FOSS projects like ReactOS, msys2, cygwin etc.? Are they aware of this thought? 5. Many Linux distributions have their own packages and patches, what about them?
Last one, in my opinion, I will not vote for the rebranding/renaming the repository because that may cause many confusion to normal users who are used to saying the name. There are hundreds of forums (also the whole Stack Exchange) where "mingw-w64" is a thing :)
Thank you <3
On 5/23/19 9:22 AM, Biswapriyo Nath wrote:
Thank you for this great idea. I agree with the cooperation. But I have some questions and concerns.
- What will happen to all the mails, patches, users contributions, issues,
releases etc.?
If we move ML, it would go to new ML. Same for issues. Transaction would have to be smooth, meaning probably keeping both active for a while.
- Where should we now send the emails and patches? I would suggest for a
separate mailing list.
Do you mean splitting mingw-w64-public into two separated lists: one for patches and one for general discussion? That could probably be done, but I'm not sure we have enough traffic to justify that.
- Will all the coding practices, restrictions (e.g. c89) of wine
repository also apply to mingw-w64 repo?
For shared parts, I guess we'd need some adjustments from both sides. I wouldn't expect it to be too bad, note that it's already true for parts that are already shared.
As a side note, Wine uses mostly C89, but it's not exactly strict about that (nor enforces that by compiler flags). What's important is compatibility with relevant environments, standard is just a tool for that, not a goal on its own. mingw-w64, on the other hand, supports and has to continue supporting applications using -std=c89, so it has stricter C89 compliance requirement already.
- What will happen to the other dependent FOSS projects like ReactOS,
msys2, cygwin etc.? Are they aware of this thought?
Why would anything change for them? Suggestions mostly involve workflow, not the end product structure. My email was meant to inform interested parties and exchange thoughts and ideas. I think their developers are on this ML, but if you think we should send it to their MLs, please forward it.
- Many Linux distributions have their own packages and patches, what about
them?
Such patches need to be rebased on each release regardless how it's done, so nothing changes. (And, as usually, ideally they would be upstreamed, but it's not relevant to this discussion).
Last one, in my opinion, I will not vote for the rebranding/renaming the repository because that may cause many confusion to normal users who are used to saying the name. There are hundreds of forums (also the whole Stack Exchange) where "mingw-w64" is a thing :)
Noted, thanks.
Jacek
On Wed, May 22, 2019 at 3:44 PM Jacek Caban jacek@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.
On 5/23/19 11:52 AM, NightStrike wrote:
On Wed, May 22, 2019 at 3:44 PM Jacek Caban jacek@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
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).
As a user, and not a coder with "a name", i might just be contributing to noise by this... Sorry if i am stepping on any toes here tho.
Since mingw-w64 is NOT a "wine project", and can be used for a lot of stuff totally outside of wine, I think it will be completely wrong to rename it to something that indicate that "now this has become a wine project". That said, i agree that mingw-w64 is somewhat misleading in a way, so I think mingw-ng would be just as fine. If the "cost" of a namechange needs to be "more features - better stuff", the world is sadly filled to the brim with ruined projects that WAS great, but is now become a spam-ridden mess of "pay-to-get-crap", or adding useless features just to get a "fresh feel".
Don't ruin a good thing just for a namechange :)
Sveinar
----- On May 25, 2019, at 8:58 PM, M. GOUJON ale.goujon@gmail.com wrote:
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. [ https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1101... | A user ] finds the name bulky (and the project pretty obscure). [ https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1101... | Another one ] 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:
- 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?
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:
- 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.
Let me split it by the region of code:
- Platform headers
We share quite a lot of those already by having changes go to Wine tree and being imported by a script. It's not pretty, but does the job. From the experience, there are minor things that often prevent using this for more headers. One of the most common is that Wine doesn't support version and family partitions guards in its headers. While they are useless for Wine, they are more important for mingw-w64 (especially family partitions). I guess that changing Wine policy should be easy and would help to share more.
- importlibs
Those are very different for both projects, keeping it separated makes probably more sense.
- CRT headers + msvcrt importlibs
In this case, following Alexandre's cross compilation work, it seems like the current solution of having headers adjusted for Wine works well and may be even better than trying to sync it. Still, a bit of coordination would be nice. What I'm esp. afraid of is how msvcrt importlib works. On mingw-w64, it needs some additions to support building with different CRTs, most notably UCRT. Those additions were already causing problems to Wine. It's fixed now, but it would be nice to make sure that we don't break again if we ever need more such additions (which is likely as UCRT support matures).
Current Wine solution of using a mix of its own importlib and default libmsvcrt.a should work fine in most cases. The case when it won't is when default mingw-w64 crt is not msvcrt-os. This is broader problem than just for Wine, it just happens to be more critical for Wine. With clang there is a solution of explicitly linking CRT DLL. We could probably try to upstream something similar to GCC.
Jacek
On 22/05/2019 21:45, Jacek Caban wrote:
- 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.
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
On Mon, 3 Jun 2019, Jacek Caban wrote: [...]
Here is how I imagine TestBot could look do:
Accept mingw-w64 patches (like it currently does for Wine patches)
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.
Francois, how does that sound?
That's probably doable but it will require quite a few TestBot modifications.
* The TestBot will need to know how to deal with multiple repositories. We need that for Wine anyway and I even have some incomplete patches for it.
* It will need to be able to identify whether a patch is against Wine or mingw-w64 which is related to the previous point.
* The TestBot normally analyses the test results to identify failures. That's in part necessary for Wine to distinguish new test failures from old ones. Presumably mingw-w64 has tests that actually pass so simply bypassing these checks and just looking at the process exit code would be enough.
* We may want separate pages for Wine's jobs and the mingw-w64 ones.
* The job submission page would likely need to offer different options for mingw-w64 patches than for Wine ones. For instance if we run mingw-w64 on Windows, those Windows VMs would need to have mingw-w64 installed which the Wine test VMs should not have. So we'd want to offer testing on a different set of VMs for mingw-w64 patches that for Wine ones.
That's one thing that separates the TestBot from other CI systems: it's not generic so where other CI systems just need to be configured for a new project, to some extent, the TestBot needs to be patched through and through.
- Build a few projects - to make sure they build.
Wine, Wine Gecko, VLC should give a good coverage.
That sounds like long running tasks so we will likely need new hardware so the TestBot can run them for every patch that gets submitted: if patches come at a rate of about one per hour, then the TestBot needs to process the resulting jobs at a rate of at least one per hour. That said we already need new hardware for PCI-passthrough for Wine (though the exact details are not set yet).
On Wed, 5 Jun 2019, Francois Gouget wrote:
- Build a few projects - to make sure they build.
Wine, Wine Gecko, VLC should give a good coverage.
That sounds like long running tasks so we will likely need new hardware so the TestBot can run them for every patch that gets submitted: if patches come at a rate of about one per hour, then the TestBot needs to process the resulting jobs at a rate of at least one per hour. That said we already need new hardware for PCI-passthrough for Wine (though the exact details are not set yet).
Those projects are rather large, so either you need quite beefy hardware, or you just run some smaller test setup for each patch (rebuild mingw-w64 and build a few smoketests maybe?) and then run a full build of those projects e.g. nightly (e.g. with a known good pinned version of those projects, which can be updated regularly). That requires a bit more manual intervention every time there's a regression though.
// Martin
On Wed, Jun 5, 2019, 3:43 PM Martin Storsjö martin@martin.st wrote:
On Wed, 5 Jun 2019, Francois Gouget wrote:
- Build a few projects - to make sure they build.
Wine, Wine Gecko, VLC should give a good coverage.
That sounds like long running tasks so we will likely need new hardware so the TestBot can run them for every patch that gets submitted: if patches come at a rate of about one per hour, then the TestBot needs to process the resulting jobs at a rate of at least one per hour. That said we already need new hardware for PCI-passthrough for Wine (though the exact details are not set yet).
Those projects are rather large, so either you need quite beefy hardware, or you just run some smaller test setup for each patch (rebuild mingw-w64 and build a few smoketests maybe?) and then run a full build of those projects e.g. nightly (e.g. with a known good pinned version of those projects, which can be updated regularly). That requires a bit more manual intervention every time there's a regression though.
For the build bot I used to run, a full build of gcc and its test suite would take several days for the cygwin target and host.
I mention that because in my experience, it's far more important to test against the breakages due to compiler changes rather than the comparatively small things that change day to day on mingw. Very few people on gcc test their changes on w64 (Jonathan Wakely is a recent notable exception), and this tends to cause entire languages to break (see Ada for example).
On Thu, 6 Jun 2019, NightStrike wrote:
For the build bot I used to run, a full build of gcc and its test suite would take several days for the cygwin target and host.
I mention that because in my experience, it's far more important to test against the breakages due to compiler changes rather than the comparatively small things that change day to day on mingw. Very few people on gcc test their changes on w64 (Jonathan Wakely is a recent notable exception), and this tends to cause entire languages to break (see Ada for example).
Yes, that's true - I locally run a nightly build of latest version of clang + latest mingw-w64, and build an assortment of projects (latest version as well with them. Building only mingw-w64 with a known-good compiler at least protects against breakage within that repo itself, but it is indeed important to test it in combination with upcoming compiler versions as well, otherwise breakage gets noticed way too late. But in such a setup, there's quite a bit of noise with intermittent breakage though, at least with clang. (I'm not familiar with upstream gcc development.)
// Martin
On 6/5/19 9:42 PM, Martin Storsjö wrote:
On Wed, 5 Jun 2019, Francois Gouget wrote:
- Build a few projects - to make sure they build.
Wine, Wine Gecko, VLC should give a good coverage.
That sounds like long running tasks so we will likely need new hardware so the TestBot can run them for every patch that gets submitted: if patches come at a rate of about one per hour, then the TestBot needs to process the resulting jobs at a rate of at least one per hour. That said we already need new hardware for PCI-passthrough for Wine (though the exact details are not set yet).
Those projects are rather large, so either you need quite beefy hardware, or you just run some smaller test setup for each patch (rebuild mingw-w64 and build a few smoketests maybe?) and then run a full build of those projects e.g. nightly (e.g. with a known good pinned version of those projects, which can be updated regularly).
We don't have that many pushes, it shouldn't be too bad IMHO. For patches submitted manually, there could be checkboxes for tests you'd like to run, so could just skip tests if they don't need to be ran.
Jacek
On 6/5/19 8:21 AM, Francois Gouget wrote:
- Build a few projects - to make sure they build.
Wine, Wine Gecko, VLC should give a good coverage.
That sounds like long running tasks so we will likely need new hardware so the TestBot can run them for every patch that gets submitted: if patches come at a rate of about one per hour, then the TestBot needs to process the resulting jobs at a rate of at least one per hour. That said we already need new hardware for PCI-passthrough for Wine (though the exact details are not set yet).
The rate of patches is much lower than one per hour. If tests would be ran on every git push, I'd say it's around 1/day on average, sometimes a few. I don't know how many manual submunitions there would be.
Thanks,
Jacek
-
Biswapriyo Nath -
Francois Gouget -
Jacek Caban -
M. GOUJON -
Martin Storsjö -
NightStrike -
Qian Hong -
Ruben Van Boxem -
Sveinar Søpler