Harmonizing mingwrt / w32api with mingw-w64

[Chris Sutcliffe-2]

While updating mingwrt to play nicely with GCC 4.4.0, it occurred to
me that there is significant duplicate effort going on between mingwrt
/ w32api and mingw-w64-crt.  In fact, the patch I ended up committing
to correct the strict-aliasing issues with mingwrt was based on
changes made to mingw-w64-crt.  I think there would be significant
gains to all things MinGW (regardless of fork, etc.) if there was a
more centralized / organized effort.

I'm therefore proposing that after the upcoming mingwrt release, we
begin to harmonize with the efforts of Kai and company.  I'm willing
to put in the effort, because I see it as a definite win / win.

Thoughts?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

Chris Sutcliffe wrote:
> I think there would be significant
> gains to all things MinGW (regardless of fork, etc.) if there was a
> more centralized / organized effort.

I agree completely.

More concretely, what exactly do you have in mind?

There's a few barriers that I can think of to ready collaboration.

1) Different licensing
2) Different technical decisions (eg we split win32api out, they don't)
3) Personality conflicts

I don't really sure a merge in the future, but I don't necessarily think
there's anything wrong with having two alternative libraries either,
other than that it divides our limited manpower.

It would be nice if we had a way to get some of the work done on
mingw32-w64 merged into our library.  Certainly they have been taking
advantage of mingwrt and w32api extensively; a little reciprocity would
be beneficial for both parties.



------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Chris Sutcliffe-2]

>> I think there would be significant
>> gains to all things MinGW (regardless of fork, etc.) if there was a
>> more centralized / organized effort.
>
> I agree completely.
>
> More concretely, what exactly do you have in mind?

Ideally it would be nice to have one central repository, but that's
not likely given the items you identified:

> There's a few barriers that I can think of to ready collaboration.
>
> 1) Different licensing
> 2) Different technical decisions (eg we split win32api out, they don't)
> 3) Personality conflicts

Additionally, given the history of w32api in particular, it would need
to remain on sourceware.

What I was thinking was trying, at a minimum, to get to a common code
base.  This would allow for easier sharing of patches between the two
branches.

> I don't really sure a merge in the future, but I don't necessarily think
> there's anything wrong with having two alternative libraries either,
> other than that it divides our limited manpower.

Agreed.

> It would be nice if we had a way to get some of the work done on
> mingw32-w64 merged into our library.  Certainly they have been taking
> advantage of mingwrt and w32api extensively; a little reciprocity would
> be beneficial for both parties.

I'm willing to start the process of attempting to merge the mingwrt
changes from mingw-w64-crt in, once I get the next mingwrt out the
door.  It would also be nice to gain alignment on w32api, but I'm not
sure about any licensing implications.  Again, I'm willing to take a
look at w32api once I work through mingwrt.

Help is always welcome.  :)

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Saturday 18 July 2009 23:38:27 Chris Sutcliffe wrote:
> I'm therefore proposing that after the upcoming mingwrt release,
> we begin to harmonize with the efforts of Kai and company.  I'm
> willing to put in the effort, because I see it as a definite win /
> win.
>
> Thoughts?

I completely agree; I've never made any secret of my opinion that
Kai's fork was a *bad* move, detrimental to the synergistic progress
of both branches of development.

FTR, Kai forked his mingw-64 project without prior consultation or
explanation.  Coming, as it did, shortly after Danny had questioned
the provenance of some of Kai's patches, it left a strong impression
of Kai behaving as a sulky child: "If I can't have my own way, and
play by my own rules, I'm taking my ball away".

We neither requested nor encouraged the fork, and we would be
delighted to see the two branches of development merged once again.  
However, we would require a formal audit of mingw-64 code, to ensure
conformance with our requirements for truly open documentation of
sources, before such a merge could be completed.

--

Regards,
Keith.

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Chris Sutcliffe wrote:
> I'm willing to start the process of attempting to merge the mingwrt
> changes from mingw-w64-crt in, once I get the next mingwrt out the
> door.

I've got a few (ideas for) patches for that...I've run across some
missing symbols in libmsvcrt.a that I'd like to see added.

Gotta go right now, but I'll post more later.

--
Chuck



------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Vincent R.]

On Sun, 19 Jul 2009 14:55:22 +0100, Keith Marshall
<keithmarshall@...> wrote:

> On Saturday 18 July 2009 23:38:27 Chris Sutcliffe wrote:
>> I'm therefore proposing that after the upcoming mingwrt release,
>> we begin to harmonize with the efforts of Kai and company.  I'm
>> willing to put in the effort, because I see it as a definite win /
>> win.
>>
>> Thoughts?
>
> I completely agree; I've never made any secret of my opinion that
> Kai's fork was a *bad* move, detrimental to the synergistic progress
> of both branches of development.
>
> FTR, Kai forked his mingw-64 project without prior consultation or
> explanation.  Coming, as it did, shortly after Danny had questioned
> the provenance of some of Kai's patches, it left a strong impression
> of Kai behaving as a sulky child: "If I can't have my own way, and
> play by my own rules, I'm taking my ball away".
>
> We neither requested nor encouraged the fork, and we would be
> delighted to see the two branches of development merged once again.  
> However, we would require a formal audit of mingw-64 code, to ensure
> conformance with our requirements for truly open documentation of
> sources, before such a merge could be completed.

I totally disagree because Kai is contributing a lot to make progress gcc
on win platform.
There a few people like that I can name like Dave Korn, Danny Smith , Aaron
Laframboise
and I am always eager to read their patch in binutils/gcc/cygwin/mingw
mailing lists because
generally it's a good move and you learn a lot about how things work.
Another remark is the fact that everytime I had an issue with binutils/gcc
on win(ce) platform I asked
Kai and HE ALWAYS tried to understand what was wrong and to fix things.
Last time I tried to do the same on mingw mailing list, I didn't feel
people were really interested to improve things or to
take in consideration some feeback (at this time I was trying to compile
something and I got some weird crash).

Another difference is the fact that mingw64 is trying to improve compiler
and not just to provide a unix-like environment.
If you want an example just have a look at Kai's last post on binutils
about a preliminary work on SEH exceptions.
So my opinion about the two projects is that mingw is like an old man that
relies on what he has already achieved while
mingw64 is a young man who looks toward future.

Actually if people are reacting like that I prefer to see two separate
projects because I wouldn't like that mingw64 project loose
its energy and ambitions by integrating people not sharing its vision.





------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Sunday 19 July 2009 15:24:42 Vincent R. wrote:
> I totally disagree because Kai is contributing a lot to make
> progress gcc on win platform.

You are, of course, entitled to your own opinion.

> There a few people like that I can name like Dave Korn, Danny
> Smith , Aaron Laframboise

And, at the time when Kai embarked on his unnecessary fork, two of
those were committed contributors to mingw32, not to mingw-w64.

> Another remark is the fact that everytime I had an issue
> with binutils/gcc on win(ce) platform I asked Kai and HE ALWAYS
> tried to understand what was wrong and to fix things.

Yet, he completely failed to appreciate the utter insanity of
discarding all of those experienced developers he had previously
been working alongside, and diluting his developer pool.

Don't get me wrong.  Kai has been productive in pursuing his goals
for mingw-w64, but imagine how much *more* productive his efforts
might have been, to the benefit of *both* mingw32 *and* mingw64, if
he had continued to work in a spirit of co-operation with those
experienced developers he left behind.

--

Regards,
Keith.

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Kai Tietz]

Keith Marshall <keithmarshall@...> wrote on 19.07.2009
17:09:19:

> On Sunday 19 July 2009 15:24:42 Vincent R. wrote:
> > I totally disagree because Kai is contributing a lot to make
> > progress gcc on win platform.
>
> You are, of course, entitled to your own opinion.
>
> > There a few people like that I can name like Dave Korn, Danny
> > Smith , Aaron Laframboise
>
> And, at the time when Kai embarked on his unnecessary fork, two of
> those were committed contributors to mingw32, not to mingw-w64.
>
> > Another remark is the fact that everytime I had an issue
> > with binutils/gcc on win(ce) platform I asked Kai and HE ALWAYS
> > tried to understand what was wrong and to fix things.
>
> Yet, he completely failed to appreciate the utter insanity of
> discarding all of those experienced developers he had previously
> been working alongside, and diluting his developer pool.
>
> Don't get me wrong.  Kai has been productive in pursuing his goals
> for mingw-w64, but imagine how much *more* productive his efforts
> might have been, to the benefit of *both* mingw32 *and* mingw64, if
> he had continued to work in a spirit of co-operation with those
> experienced developers he left behind.

Hello,

I would liked to reply to the ongoing discussion on mingw-dvlr by myself
earlier, but I had to wait for this until today, as the subscribed e-mail
is that from my office and I wanted to speak with other team-members
before.

First we appreciate that Chris raised this discussion. And I attended it
by
SF mailing list viewer interested.

But some points there said are simply not true.
A long time ago (already 2005) the company we were working for wanted to
port our software to 64bit windows. As of the fact that a large part of
the software is using ObjectiveC there is only one compiler on windows to
compile it. GCC. So we began to search for a 64bit gcc/binutils port. But
nothing was there. Not on mingw not anywhere else. Just some postings in
newsgroups saying "yes we would love to have it, but no time/knowledge to
do it." GCC4 was not even really windows 32bit ready at that time.
We talked to mingw people but got similar responses. We also offered to
help and to do it on our own, together with the mingw project.

The port was done by the company I am still working for. Me (Kai) was one
of the team, which did the white-room port beginning 2006. After the port
was mostly complete we tried to provide this port to mingw.org. As at this
time I was still under NDA (which was released now 6 months ago, so that I
am allowed to write about this more openly), so I couldn't anwser all
questions raised. But there weren't much question, mostly offending and
even rumors were spreaded. Nothing of the reaction of mingw.org's
leaderships has shown to us a perspective or a target in co-operation for
this. So we decided to put this code into a project on SF, because it
should become open source and we were in need to have an public repository
(this we did in October 2007).  In 2008 the company OneVision offical
donated the sources and headers to me in person (and for mingw-w64) under
the condition, that it has to remain open source.  At this point, we began
as mingw-w64 project to increase our support also for x86 support. The
major politic of mingw-w64 is to work for further development strict with
upstream (open available) version without private patches to external
projects. Also we never made difference in user support, if somebody is
using a compiler from packager x, or y, as this doesn't help the user
querying questions. Also we have regular builds for developers of upstream
source, so we can verify and check very quickly, that upstream source
keeps working.

The major point that we reduced co-operation - as mingw-w64 and before
project start - is, that we were offended and defamed by persons (which
are maintainers of mingw.org) more then once. Why should we accept this
silently and play nice to a bad game. I never offended somebody from
mingw.org team by open mailing-list flame, I tried to avoid putting oil
into the fire. But I had to see pretty often on your ML the statement for
users, which were searching for gcc windows 64-bit support, the statement
"We don't support this fork.". Well does this shows the wish of
co-operation? Honestly we are no children and no baboons, and those kind
of talks and habits common to mingw.org are childish and callow. And those
kind of discussion lead nowhere. As long as there is such a management of
mingw.org, which prefers to talk over, but not with somebody, we as
mingw-w64 have problems to accept and take them serious.

Secondly, to defame my work on gcc as selfish and just good for mingw-w64
is ignorance and just shows the real issue here. Most patches I did where
directly related to 32-bit as well as for
64-bit code of binutils and gcc. A lot them are one reason why 4.4.x and
binutils works better for 32-bit than for a long time. Mingw.org was and
will benefiting by them greatly. We provide some of our patches for shared
runtime parts (because we don't want to do battle on users-head) to
mingw.org, as we have the strong opinion that this is a win/win situation
for both projects. We prefer to make things real, instead of just talking
about it, and trying not to accuse.

Cheers,
Kai Tietz and Roland Schwingel

---
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Strasse 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementaerin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Strasse 9 ? 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschaeftsfuehrer:
Manuela Kluger


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[NightStrike]

On Sun, Jul 19, 2009 at 9:55 AM, Keith
Marshall<keithmarshall@...> wrote:

> On Saturday 18 July 2009 23:38:27 Chris Sutcliffe wrote:
>> I'm therefore proposing that after the upcoming mingwrt release,
>> we begin to harmonize with the efforts of Kai and company.  I'm
>> willing to put in the effort, because I see it as a definite win /
>> win.
>>
>> Thoughts?
>
> I completely agree; I've never made any secret of my opinion that
> Kai's fork was a *bad* move, detrimental to the synergistic progress
> of both branches of development.
>
> FTR, Kai forked his mingw-64 project without prior consultation or
> explanation.  Coming, as it did, shortly after Danny had questioned

This is dead wrong.  We forked because Danny requested it.

> the provenance of some of Kai's patches, it left a strong impression
> of Kai behaving as a sulky child: "If I can't have my own way, and
> play by my own rules, I'm taking my ball away".

...And this is the reason why we don't bother working closely with
mingw.org.  The antagonism on these mailing lists is massive, and we
just plain don't have time to deal with it.  I had sent a personal
message to you, Keith, pleading with you to do something about the
negativity spread throughout yours and Earnie's posts, but received no
response.  So, we moved on.

That's the big difference here.  The mingw-w64 team makes progress.
And a lot of it.  The biggest thing we do differently is that we treat
people wonderfully.  Our users love us, upstream maintainers are
ecstatic about our support, and internally we have a great working
dynamic.  Mingw.org lacks those things.

> We neither requested nor encouraged the fork, and we would be
> delighted to see the two branches of development merged once again.
> However, we would require a formal audit of mingw-64 code, to ensure
> conformance with our requirements for truly open documentation of
> sources, before such a merge could be completed.

Merging with you as mingw.org requires working with you directly.
We've tried time and time again, and have been met with nothing but
disdain, anger, flames, hatred, and overall unprofessional nonsense.
Merging just isn't feasible until you adjust your attitude
significantly and create an environment where we *can* collaborate.
Until then, we are happily making everything in the toolchain suite
better for **both** mingw.org as well as mingw-w64.

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie]

Quoting NightStrike <nightstrike@...>:

All, I can say is research the archives.  We've more than once asked  
for cooperative effort.  If we can find harmony between the projects  
it will have to be with cooperative effort between all parties and I  
have yet to see that.  You're argumentative vain in your response for  
harmonious work is an example of how not to be cooperative.  Harmony  
or not between the projects, we need to move forward with 64bit support.

--
Earnie


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie]

Quoting Kai Tietz <Kai.Tietz@...>:

Kai, I probably have in the past pored fuel to the flame of content.  
I appreciate your honesty in your lengthy recitation of how you view  
the history of MinGW-64 and thank you for it.  I think it would  
benefit us to forget the past and look toward the future and allow our  
two ventures for MinGW to strive to become one.  Let's put our  
feelings aside and work toward making GCC and MinGW the best it can be.

Kind regards,
Earnie


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[NightStrike]

On Tue, Jul 21, 2009 at 10:04 AM, Earnie
Boyd<earnie@...> wrote:
> Quoting NightStrike <nightstrike@...>:
>
> All, I can say is research the archives.  We've more than once asked
> for cooperative effort.  If we can find harmony between the projects
> it will have to be with cooperative effort between all parties and I
> have yet to see that.  You're argumentative vain in your response for
> harmonious work is an example of how not to be cooperative.  Harmony

I wasn't arguing.  I was stating the facts behind why we operate
without you guys.  We've given up on you.

> or not between the projects, we need to move forward with 64bit support.

On the contrary, we already have moved forward with full support of
everything, including the support of our user base.  It's you who
needs to make a decision on how you are going to proceed.

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[NightStrike]

On Tue, Jul 21, 2009 at 10:17 AM, Earnie
Boyd<earnie@...> wrote:
> Quoting Kai Tietz <Kai.Tietz@...>:
>
> Kai, I probably have in the past pored fuel to the flame of content.
> I appreciate your honesty in your lengthy recitation of how you view
> the history of MinGW-64 and thank you for it.  I think it would
> benefit us to forget the past and look toward the future and allow our
> two ventures for MinGW to strive to become one.  Let's put our
> feelings aside and work toward making GCC and MinGW the best it can be.

You need to realize that a huge contributor as to why mingw-w64 is so
very successful is how we treat our users.  As an example, mingw.org
users are ridiculed and ignored just for having an email with
disclaimer text at the bottom that they cannot control.  We do not do
this kind of thing.  The entire attitude of mingw-w64 vice mingw.org
from front to back is different, and we need to see movement on your
side more aligned with the values we uphold.  This isn't just about
being nice to Kai and myself (I put myself in there, though I noticed
how different your replies were to the two of us).  This is about the
overall attitude and motivation of the mingw.org project.

There is a general feeling that users have when they come over to our
project.  They consider mingw.org to be "just plain mean."  mingw-w64,
on the other hand, makes users feel welcome, and we help them through
every problem.  We actively maintain many avenues of support that
users want, including one hated on by mingw.org.

Moreover, we have worked hard to establish relations with many
upstream projects.  They now view us very favorably because of how we
communicate and work with them to further the various projects
involved.  mingw.org takes a different, conflicting approach regarding
interfacing with the outside world, although you can still benefit
from the improvements that we make.

This kind of thing is paramount for us to reassociate with mingw.org.
Currently, mingw.org has too many negatives that need to at least be
acknowledged and addressed if not thoroughly cleaned out.

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Monday 20 July 2009 16:07:16 NightStrike wrote:
> > FTR, Kai forked his mingw-64 project without prior consultation
> > or explanation.  Coming, as it did, shortly after Danny had
> > questioned
>
> This is dead wrong.

Before you jump in with both feet, to make such a claim, it would be
prudent to check your facts.  Although I made this statement on the
basis of my memory of events from two years ago, it is an accurate
recollection.  It is *you* who are "dead wrong", and ten minutes on
gmane is sufficient to expose your deceit.

> We forked because Danny requested it.

He did no such thing; you forked because Kai unilaterally decided to
do so, and, as I said, without prior consultation.

Perhaps you are simply confused by this:
http://thread.gmane.org/gmane.comp.gnu.mingw.devel/2528/focus=2534

However, if you read that IN ITS PROPER CONTEXT, it becomes clear
that Danny's request to keep mingw-w64 headers separate:--

1) Came *after* Kai's unilateral decision to present us with the
"fait accompli" of a forked project.

2) Was not a request to create a fork, (that had already been done,
without any request from anyone associated with MinGW), but simply
to defer a merge of mingw-w64 headers into MinGW's CVS, until such
time as a proper audit could be completed, and certain proprietary
information, which *may* have been illegitimately incorporated, had
been removed.

3) Was not intended as a request from the MinGW Project, (although
it did reflect our POV at the time).

To set this in proper context, this prior thread is also relevant:
http://thread.gmane.org/gmane.comp.gnu.mingw.devel/2334/focus=2371

Note that at the time, Kai had raised the question of merging his
mingw-w64 headers into CVS HEAD.  He was invited to break it down
into manageable patches, for appropriate review.  A perfectly polite
request, but instead of complying, and without any further word, he
created his fork.  It may not have been intentionally so, but it
definitely appeared infantile, leading to...

> > ... a strong
> > impression of Kai behaving as a sulky child: "If I can't have my
> > own way, and play by my own rules, I'm taking my ball away".
>
> ...And this is the reason why we don't bother working closely with
> mingw.org.  The antagonism on these mailing lists is massive, and
> we just plain don't have time to deal with it.

The antagonism is perpetrated primarily by *you*; insolent and
deceitful in the extreme.  Why should you expect *us* to be bothered
to deal with *you*?

> I had sent a personal
> message to you, Keith, pleading with you to do something about the
> negativity

You did, and in response, I attempted to open a dialogue with Kai,
(which is what you actually asked me to do); I was not granted even
the common courtesy of a reply.  Faced with such insolence, what
more would you have me do?  I wrote you off, as a lost cause.

I thought Earnie was extremely graceful to offer an apology for any
part he may have played, in exacerbating the antagonism.  Kai was
quick to exhibit a modicum of grace in acceptance; what a shame that
he lacked the grace to also apologise for the part he played, for it
was he alone who created the circumstances leading to the antagonism
in the first place.  (It would also be nice if he were to offer an
apology for the shamefully deceitful misrepresentation of historical
fact, at least in part, which he posted earlier this week, but I
guess that may be too much to hope for).

There are always two sides to any dispute, and blame must usually be
apportioned equally to both.  The MinGW Project would be delighted
to mend the rift, and to work in harmonious co-operation with
mingw-w64; we have already begun the effort to mend the bridges.  
However, bridge mending must be instigated on both sides of the
rift.  With apologies for mixing metaphors, the ball is now in your
court.

--

Regards,
Keith.

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr