On 3 October 2013 11:24, Matthew Brush <mbrush@codebrainz.ca> wrote:
On 13-10-02 05:19 PM, Lex Trotman wrote:
All Developers,

Its time we deprecated windows support!!

The windows code in Geany is:

- unmaintained and bit-rotting

- buggy

- holding us at an unreasonably old GTK version

- hard to maintain due to being hacks on top of hacks

- few of the developers have access to a representative development setup
(no WinXP on a VM is hardly representative)

Since there has never been a case of removing support for a platform before
(that I know of) we don't have a process for doing it.

Therefore I propose that the windows version be deprecated, announcing it
on the website, user ML and #geany startup message and anywhere else it
might get through.

If this does not result in contributors who support the windows version
coming forward and actually making a difference in the code and the user
support then Windows should be dropped in a couple of versions.

I don't have any windows systems, don't use it and can't develop for it,
but I have always noted when I was aware that some issue would impact the
windows version, and have tried to help people who have had difficulties
with Geany on windows where I could.

But I have run out of patience.


Heh, you're the only one with commit access that doesn't have at least a VM to test Windows stuff on :)

But nobody actually does anything to fix the problems, so how would we know :)
 

Anyway, I'm against removing Windows support, since a large portion of Geany's users (anecdotally, from IRC and bug tracker) are running Windows, but I am totally for:

- Removing buggy, non-trivial, non-maintained, win32-specific code (ie all of win32.[ch]).
- Removing all #ifdef G_OS_WIN32 guards/blocks unless strictly required (since we're using G* we should need few if any such guards to be cross-platform).
- Removing 2 of 3 build systems and using *one* that can compile Geany on all platforms (ex. fix Autotools to work in MSYS, or only using Waf, or maybe CMake or something else).
- Having nightly/continuous build for Windows using above build system and environment, so non-Windows-using developers can know if they broke Windows build (IIUC current Win32 nightly builds using cross-compilation from Linux, completely separate from Win32 release build). Not sure this is possible unless we can run a VM on the server though.
- Not officially caring about WinXP since it's hasn't "mainstream" support by Microsoft since 2009 (and is officially EOL next year).
- Enabling GTK+3 support in Windows release and using latest supported GTK+ bundles provided by upstream, so were not fighting 5+ year old bugs that likely have been fixed since.
- Not "working around" bugs in G* win32 stuff with #ifdef/win32.c hacks, but rather just filing a bug report upstream and pointing anyone hitting the bug to the upstream ticket.
- Having a script and/or documentation on the Windows release/installer creation process so it can be updated and understood by all developers.

I think with most of the above it would alleviate the maintenance burden related to Win32 support.

That seems a likely nice way forward for windows support, if it is continued. But this requires work, and my point is that, at the moment, ***nobody*** is going to do it.  

Since nobody has actually come forward and demonstrated that they have the capability and the ***will*** to maintain windows support, we should warn everyone that this is the case.  If someone(s) actually does the things you have listed above, then great, thats the best outcome.

But lets face reality, if no maintainers who ***will*** fix windows can be found, kill support for that platform.  An unmaintained platform should not dictate the future of the project.

Cheers
Lex
 

Cheers,
Matthew Brush

_______________________________________________