Updating legacy ci

[zlonast]

Update the environment to the same cabal from 9.12.2 to 8.8.4

[zlonast]

@Mistuke Can you suggest how I can help, it seems that in the conditional cabal everything has been working for a long time, can we take a cut-down config only for Windows?

[zlonast]

#244

[bgamari]

We still need to remove Appveyor integration from this repository (and indeed the entire haskell organization). Sadly, I don't have the necessary privileges to do this. @Bodigrim, perhaps you could handle this?

It appears that until this is done we will still have failing Appveyor checks on all PRs.

[Mistuke]

Any particular reason why this was merged without me having a chance to review?

[Bodigrim]

We still need to remove Appveyor integration from this repository (and indeed the entire haskell organization). Sadly, I don't have the necessary privileges to do this. @Bodigrim, perhaps you could handle this?

As an org admin, I revoked Appveyor access to this repo. The only other repo it continues to have access is https://github.com/haskell/HTTP, but that one does contain .appveyor.yml, so I assume it's for purpose.

[bgamari]

@Mistuke two related reasons:

• I have noticed that CI has been broken for a rather long time, and
• that brokenness seems to have resulted in System.Win32.File.Internal fails to compile due to missing _WIN32_WINNT #245, which is now affecting other boot libraries' CI (e.g. Fix 'since' tags in System.Process.Environment.OsString process#346)

Apologies if it was a bit hasty, @Mistuke, but I did want to resolve #245 quickly since I am working on finalizing submodules for 9.14 and Win32 is currently holding this up. Regardless, do by all means continue to iterate on the setup.

[bgamari]

As an org admin, I revoked Appveyor access to this repo. The only other repo it continues to have access is https://github.com/haskell/HTTP, but that one does contain .appveyor.yml, so I assume it's for purpose.

Ultimately I think it would be a good idea to just standardize on Actions for GitHub-hosted repositories at this point but I don't think I will execute on this in the short-term.

[Mistuke]

@bgamari that's completely an unfair assessment. I've always been testing these locally.

Quite frankly it's a bit annoying to be overridden on something no one asked about.

Perhaps it's time I give up maontainership of win32. I wasn't notified of that breakage and changes seem to be merged without any consultation.

So I'm happy to stand aside.

[bgamari]

@bgamari that's completely an unfair assessment. I've always been testing these locally.

Quite frankly it's a bit annoying to be overridden on something no one asked about.

I'm sorry for the confusion, Tamar. I should have pinged you before pulling the trigger on this. I had thought that this would be a fairly unobjectionable change. I hope we can all agree that boot libraries have green CI in the future but the maintainer should be kept in the loop.

Perhaps it's time I give up maontainership of win32. I wasn't notified of that breakage and changes seem to be merged without any consultation.

So I'm happy to stand aside.

I do hope you reconsider. If so, I will be more be conservative in intervening and try to communicate more clearly in the future.

[Mistuke]

@bgamari that's completely an unfair assessment. I've always been testing these locally.
Quite frankly it's a bit annoying to be overridden on something no one asked about.

I'm sorry for the confusion, Tamar. I should have pinged you before pulling the trigger on this. I had thought that this would be a fairly unobjectionable change. I hope we can all agree that boot libraries have green CI in the future but the maintainer should be kept in the loop.

That's all I really wanted, no one ever mentioned anything was broken, The fix for #245 changes the minimal supported version, and has an effect on the imported symbols. Win32 has _compat.h files for handling this, changing _WIN32_WINNT is not how it's normally done, there are two files that do this in Win32, but those were imported from Win32-extras and seems like I missed them during cleanup. Unconditionally defining it would e.g. conflct with packges that have a higher minimum version (i.e. https://github.com/ghc/ghc/blob/3bf6720eff5e86e673568e756161e6d6150eb440/libraries/ghc-internal/ghc-internal.cabal.in#L504) but also not work for older GHCs which may not have the constant at all, yet run the binary on newer OSes.

My suggested fix would have been to add it to a compat header https://github.com/haskell/win32/tree/master/include which still allows GHC to be in control of the minimal supported version.

Perhaps it's time I give up maontainership of win32. I wasn't notified of that breakage and changes seem to be merged without any consultation.
So I'm happy to stand aside.

I do hope you reconsider. If so, I will be more be conservative in intervening and try to communicate more clearly in the future.

@bgamari To be clear, I'm happy to continue as long as people want me to and I didn't mean for this to be any kinda of pressure at all. % some issues with github notifications (for some reason gmail hides notifications I'm not @ in directly) I always try to be responsive.

But... I was unhappy for a number of reasons:

1. The pull request unilaterally drops support for older GHCs which I have gone through great lengths to support because I try not to make win32 require newer GHCs. It's after all just a platform API binding.
2. It doesn't build the package with -Werror, which I've always done as it points out cases where the Haskell code has erroneously created a conflicted #define that overlaps with the C code.
3. It calls cabal through msys2, which means it inherits a posix environment where win32 is supposed to be a native library. I've intentionally never done it through msys2 as I always wanted to ensure it's buildable without a posix environment
4. it drops 32-bit support which I've always maintained because the headers are different and point out gaps and assumptions. It also ensures that all APIs use CPP for calling conventions, to make supporting new architectures easier, like the code recently added for AArch64.

As I mentioned on IRC I'm traveling for work and would have finished the branch I'm working on this weekend so I was quite surprised to see it merged.

[zlonast]

It is worth noting that the entire repository feels abandoned for several reasons:

1. Until yesterday, the repository did not have CI.
2. The repository does not have tests.
3. The repository does not have a unified formatting style.
4. There is no documentation on platform-specific behavior and error handling, causing them to be overlooked in dependent repositories.
5. There is no CONTRIBUTING.md file that would help with this.
6. Support for outdated versions creates a high barrier to entry. New contributors lack the knowledge and tooling to work with these legacy targets, making contributions significantly harder.
7. There is support for 32-bit, which was thrown out of ghc after 9.0, which makes it even more difficult for an external contributor to contribute.

As a result, repositories that import this package prefer to make their own bindings, which is why we most likely already have different behavior.

@Mistuke Ultimately, the health of an open-source project depends on enabling new contributors. While expanding support has value, the current state (legacy version support, lack of tooling/docs) creates barriers that outweigh those benefits and fragment the ecosystem (leading to incompatible forks). Prioritizing contributor accessibility would strengthen the package in the long term.

Another result is that it is very strange that the maintainer is defending his contribution from CLC members, I think that the reaction to @bgamari 's actions was very strange and unfounded.

[Mistuke]

It is worth noting that the entire repository feels abandoned for several reasons:

1. Until yesterday, the repository did not have CI.

That you saw yes. Now it has a broken CI as well as it doesn't do what I expect it to do.

3. The repository does not have tests.

Because the Win32 tests are part of GHC, you'd know this if you actually bothered to ask.

5. The repository does not have a unified formatting style.

Because the repository is a merging of various other bindings.

7. There is no documentation on platform-specific behavior and error handling, causing them to be overlooked in dependent repositories.

The documentation is on MSDN and always have been. It's a platform binding. There's no need to duplicate documents. Copying documentation inline makes them easily out of date as Microsoft changes the functions. The version of win32 does not matter because what it supports is determined by the operating system. We've never linked to them because MSDN links has never been particularly stable. One example is that it used to be called msdn, now it's learn.microsoft.com

You're clearly not understanding the purpose of this package and the reason the bindings are lightweight.

9. There is no CONTRIBUTING.md file that would help with this.
10. Support for outdated versions creates a high barrier to entry. New contributors lack the knowledge and tooling to work with these legacy targets, making contributions significantly harder.

Which is why there's a maintainer that helps with this. This is your first time contributing anything to the project. I don't see why you feel so entitled.

12. There is support for 32-bit, which was thrown out of ghc after 9.0, which makes it even more difficult for an external contributor to contribute.>

Again, you missed the point of the 32-bit contribution. I've been maintaining it far after GHC dropped support for it. I can tell you. it's not hard. You just need to know what you're doing.

15. As a result, repositories that import this package prefer to make their own bindings, which is why we most likely already have different behavior. @Mistuke Ultimately, the health of an open-source project depends on enabling new contributors. While expanding support has value, the current state (legacy version support, lack of tooling/docs) creates barriers that outweigh those benefits and fragment the ecosystem (leading to incompatible forks). Prioritizing contributor accessibility would strengthen the package in the long term.>

And contributors need to send useful changes. Not something against the will of the maintainer just because they think it's useful.

Another result is that it is very strange that the maintainer is defending his contribution from CLC members, I think that the reaction to @bgamari 's actions was very strange and unfounded.

I wasn't defending any contributions as I haven't made any. This PR should have never been merged without consulting me on the CI I wanted. Sorry just because you send a request, doesn't mean it has to be done the way you want.

[zlonast]

@bgamari To be clear, I'm happy to continue as long as people want me to and I didn't mean for this to be any kinda of pressure at all.

Lol, I hope such people will continue to be found :)