Re: Should We Start Dropping Windows XP Support?

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 30 December 2014 at 12:48, Martyn Russell <martyn lanedo com> wrote:

> > I work on an audio product called Mixbus which uses gtk+ (albeit gtk2,
> > rather than gtk3):-
> >
> > http://harrisonconsoles.com/site/mixbus.html

we're definitely not dropping support in GTK 2.x; that branch is done,
for better or worse.

we're talking about dropping XP code paths directly in GLib (by and
large the threading primitives implementation) and GTK+ 3.x (mostly in
the composited/non-composited code paths of the windowing system).

> > I've been arguing for a year or more that we should phase out XP support
> > - but the more senior devs don't agree.  Why?  Because a surprising
> > number of our Windows users are still running XP (probably more than a
> > third).  XP is still far more common than you might think.
>
>
> I agree that we should base this decision on numbers.

I would not use a single application usage data, however skewed it may
be, though, to be quite fair.

if we look at OS usage statistics for websites, XP goes from <5%
(below Linux! we won! oh, wait…) to ~14%, which is far below 33%. it's
also steadily decreasing month to month, and Microsoft terminating
support for XP was likely the final nail in the coffin. yes, we all
know people not upgrading their machine because everything else is
terrible, but it's a balancing act, and we need to ask ourselves if
we're targeting the retro-computing scene or not.

we also need to look at the context in which XP is used. for instance,
John's application looks pretty much like an "appliance", and targets
a fairly specific user base that won't upgrade because it has no
incentive to. the application works, today, just as desired. updating
is pointless. likely, the OS in question is running on an isolated
machine, with minimal interaction with an hostile environment, so
security updates are less of an issue. is that a common scenario? I
don't think so.

another thing we need to look at is the maintainership burden on the
platform and the chance for regressions. we don't have Windows
autobuilders, and we definitely don't have Windows XP ones at that.
this means that any potential regression introduced in GLib and GTK+
won't get caught automatically, and instead will be caught by
application developers whenever they decide to update their
dependencies. cue grief and accusations of breaking everything. if on
Linux-based platforms application developers test toolkit APIs with 12
months delays, on non-Linux platforms the cycle is even longer. we
simply don't have a feedback loop tight enough to be useful. that's
where autobuilders and continuous integration usually come in.

Windows applications are expected to take their dependencies with
them, so it's entirely possible to have a Windows XP build that ships
with an older version of GLib, in case GLib dropped Windows XP
support. we could even have a separate branch of GLib that would make
it easier to target for application developers, and maybe a final
Windows XP build on gtk.org. we could have occasional cherry-picks,
like we do for gtk-2-24. obviously, it'd help to have regression
testing, but since nothing appeared in the last 15 years, I won't hold
my breath for it. I'd love to be proven wrong, though.

there's also the aspect of other projects in the larger free and open
source software ecosystem. what is Firefox doing? what is LibreOffice
doing? what is Qt doing? are we the last holdout?

finally, while GLib is probably a point of contention where debate on
usage statistics is good to be had, I think dropping Windows XP
support from GTK+ 3.x makes much more sense; there is a lot less
legacy there, and we're starting to assume capabilities from the OS on
every other backend, which makes it harder to justify degrading the
overall featureset of the toolkit in order to support an OS from 2001
that won't see any update.

ciao,
 Emmanuele.

-- 
http://www.bassi.io
[ ] ebassi [ gmail com]