Who make the final decision?
Wanabe, are you (or, do you want to become) the maintainer of mingw port?

No, I am not. (and I do not want to)

I'm very dissatisfied with the current state, but I don't have a mind to
object to the maintainer's decision.
Therefore, I ask it again.
Who is the maintainer and who make the final decision?

I'm very sorry to commit r29320 hastily.
This is really, really my fault.

I asked for a Nakada-san's advice of this issue.
Because he is the maintainer of mingw32.
He said config.sub should be reverted to automake-1.11.1's.
I did it because I thought it can be covering my losses.

And the change of win32/mkexports.rb is my fault.
I guessed that there is no effect for other platform by this change.

But now I realize that I exceeded my authority.
I want to ask back to the maintainer of win32/mkexports.rb (who?) for
acceptability of it.
I guess I should revert the change until hear this decision, shouldn't I?

Thank you Aaron for the vote, but I'm interested first in understand
what are the roles and duties of a port maintainer.

100% of the work done for RubyInstaller is around mingw and mingw-w64
versions of GCC, I can provide a daily test base and work on this.

However, on this same thread wanabe committed a patch I generated
which only touched mingw section of mkexports. If I has given commits
bits, I would have done the same.

It seems to me (maybe I am wrong) that wanabe only reverted because he
is not the mingw maintainer. As far as I can tell, nobody is. If you
were the mingw maintainer, I think you would decide how to fix mingw
problems.

I would like to understand better the roles and responsibilities
before offering myself as maintainer in the light of possible
"mistakes" I could make in the quest of a better MinGW support for
Ruby.

I think your responsibility would be "make sure ruby works with mingw".
;-)

Please apologize my lack of understanding of Ruby development hierarchy, but the revert of 'mingw' specifics in mkexports breaks the mingw-w64 work.

Oh, you don't have to apologize.
(And, of course, wanabe-san doesn't, too.)

Who is the maintainer that provides "best effort" in relation to MinGW support? I would like to discuss this and future MinGW work without causing you guys lot of conflicts.

Agree.
The problem is not wanabe-san's revert, but a lack of responsibility
of MinGW port.

Currently, nobu is the maintainer of MinGW port.
I know him well, and everyone knows that he is the special about
hacking ruby.
However, he is not living on Windows now.
Moreover, he doesn't have 64bit Windows environment.
I guess that it is too difficult to maintain it in such situation
even if he is the special.
We should change the current state in some shape.

Who is the maintainer that provides "best effort" in relation to MinGW support? I would like to discuss this and future MinGW work without causing you guys lot of conflicts.

Agree.
The problem is not wanabe-san's revert, but a lack of responsibility
of MinGW port.

Currently, nobu is the maintainer of MinGW port.
I know him well, and everyone knows that he is the special about
hacking ruby.
However, he is not living on Windows now.
Moreover, he doesn't have 64bit Windows environment.
I guess that it is too difficult to maintain it in such situation
even if he is the special.
We should change the current state in some shape.

Hello Mr. Nakamura,

Thank you for your answers.

I'm actively using MinGW/mingw-w64 in both native (Windows) and for
cross-compilation (Linux/OSX targeting Windows)

All the work towards 64bits Ruby under MinGW is still young, but all
the cross-compilation issues are needed right now to simplify things
for Ruby developers and their Windows support.

I'm willing to provide instructions to nobu so he can cross-compile
exactly the same way I'm doing from my OSX computer (or a Linux one,
doesn't matter)

As for the native versions, I would happily report issues and provide
patches to any encountered problem that blocks compilation or
execution, has been done already over the past years.

I will be very happy if all the existing issues for the which I
provided patches can be reviewed.

I'll happily accept become a maintainer if that is required to ensure
a proper MinGW support for Ruby.

Thank you.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

The 32bits (i686-w64-mingw32) issue has been solved, and it correctly generates i386-mingw32 as RUBY_PLATFORM

However, the 64bits version one still fails as it generates x64-mingw64 which is incorrect.

Either the platform should be 'x86_64-mingw32' or 'x64-mingw32', to match VC x64 builds. There is an eternal discussion on mingw and mingw-w64 mailing lists about how 'mingw32' stuck and how hard is to change it. Usage of 'mingw64' do not correspond to any GNU triplet, as mentioned before.

Steps to reproduce this issue:

1) Download a Linux or Darwin binaries for x86_64-w64-mingw32 from the Automated build page:

I would like to ask Mr. Usaku NAKAMURA to review it as mswin64 != mingw64, so there is no reason for canonicalize it as VC builds.

me? not nobu?
# I am the maintainer of mswin32/mswin64, but not of mingw.

Ah, the name of port "mswin64" means that it is targeted to
use Win64 API set.
"mswin32" and "mswince" means similar.
But "mingw*" does not seem to be similar, and the meaning is
fundamentally different from the names of other platforms.
I cannot suggest any logical proposal with this state.
After all, the maintainer of this platform might draw a conclusion
according to his reason.

I understand, but according to the comment, canonicalize according to
mswin*, was my understanding you discussed this with Nobu.

Ah, the name of port "mswin64" means that it is targeted to
use Win64 API set.
"mswin32" and "mswince" means similar.
But "mingw*" does not seem to be similar, and the meaning is
fundamentally different from the names of other platforms.
I cannot suggest any logical proposal with this state.
After all, the maintainer of this platform might draw a conclusion
according to his reason.

Thank you for your observations, assigning to Nobu for approval.

Regards,
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry