On 5/23/19 11:52 AM, NightStrike wrote:
On Wed, May 22, 2019 at 3:44 PM Jacek Caban <ja...@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
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
