[Geany-Devel] On Deprecation of Platforms

[Lex Trotman]

On 3 October 2013 11:24, Matthew Brush <mbrush at 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
>
> ______________________________**_________________
>
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-**bin/mailman/listinfo/devel<https://lists.geany.org/cgi-bin/mailman/listinfo/devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20131003/3e2fa6d7/attachment.html>