Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Martin Storsjö]

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



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Jacek Caban]

On 6/5/19 9:42 PM, Martin Storsjö wrote:

On Wed, 5 Jun 2019, Francois Gouget wrote:


3. 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


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Jacek Caban]

On 6/5/19 8:21 AM, Francois Gouget wrote:

3. 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


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Wine and mingw-w64 cooperation [mingw-w64 name]

[M. GOUJON]

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 
 
finds the name bulky (and the project pretty obscure).
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).


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Francois Gouget]

On Mon, 3 Jun 2019, Jacek Caban wrote:
[...]
> 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.
> 
> 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.


> 3. 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).


-- 
Francois Gouget   http://fgouget.free.fr/
  Any sufficiently advanced bug is indistinguishable from a feature.
-- from some indian guy


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation [mingw-w64 name]

[Sveinar Søpler]

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  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/1101258-wine-mingw-w64-might-tighten-up-their-relationship-possible-winesdk
> | A
>   user ] finds the name bulky (and the project pretty obscure).
> [
> https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1101258-wine-mingw-w64-might-tighten-up-their-relationship-possible-winesdk?p=1101443#post1101443
> | 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).

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[NightStrike]

On Wed, Jun 5, 2019, 3:43 PM Martin Storsjö  wrote:

> On Wed, 5 Jun 2019, Francois Gouget wrote:
>
> >> 3. 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).

>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] crt: Update dnsapi library

[Liu Hao]

在 2019/6/4 下午10:38, Biswapriyo Nath 写道:
> ...
> 
> 
> 

Thank you. I pushed this patch.


-- 
Best regards,
LH_Mouse



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public