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