Rant: So you want help?

[Thomas Friedrichsmeier]

Hi,

On Saturday 06 November 2010, Ralf Habacker wrote:
> Are you aware that adding an additional executable with mostly the same
> functionality may result into more problems than to solve ?

I am aware that transitions can be painful.

But first, to state the problem I'm trying to solve:
There is no 4.5.x release, still. Perhaps it will be done in the "traditional" 
way sooner or later. But for all I've heard, having timely releases will be an 
issue again, and again, and again in the future.

*One* reason for this is that the barriers to a release seem tremendously 
high. Supporting two or three compilers *at once* looks like one of the 
central barriers to releasing anything at all. For instance, I'm always low on 
hard disk space, and I don't even have a 64bit windows. So, if *I* am to 
participate actively in releasing, I need to find a way to make it managable. 
If you're saying the release process is hard to break up, *and* you need to do 
it for three compilers, then *I* am not the volunteer you're looking for. 
Sorry.
 
The key idea, here, is that different compilers can be handled by (potentially) 
independent teams (read: those you really care about having an end-user 
installer for that compiler) and on (potentially) independent schedules.

> There is a concept that the last recent installer is always named
> kdewin-installer-latest.exe. The url of this installer is spread all
> around the world, has been linked into many websites and is downloaded
> up to 100000 times a month.  When this option is removed from the
> installer and for each compiler a different url is provided, who is
> going to talk with all those website maintainers to add additionals link
> in case more than one compiler is supported.

Simple suggestion: kdewin-installer-latest.exe will point to the MinGW 32bit 
incarnation.

So we want to support compiler diversity, but there's no reason why we 
shouldn't encourage a compiler default for end users. MinGW 32bit looks like 
the obvious choice to me, because
- 32bit will work for all users
- GCC is the predominant compiler in the KDE world, so creating a MinGW based 
release will typically be least trouble, compared to any other compiler.

So websites will have to provide more links - if they care. But in fact 
websites that do care, will finally get a decent possibility to enforce this. 
E.g. because they provide add-on binaries that only work with *one* of the 
compilers, or because their application is known to malfunction with another 
of the compilers, etc.

MSVC-users will be told by the kdewin-installer-latest.exe that they need to 
install from scratch. Tough luck. But then, it's not like updating an existing 
installation has been a one-click-wonder, up to date.

> Or if only one compiler is supported, who will explain users 10 times a
> day, why compiler xyz isn't available anymore.

Who will explain users 10 times a day why 4.5.x release is not available, yet? 
Who told users of MinGW3 installations why they were not finding any updates in 
the 4.3.x and above directories on any mirror (and this transition, too, could 
have been ameliorated by breaking up the installer, IMO)?

> Having all this
> possibilities in one installer makes it able to change installers
> behavior from release to release without any broken links and increased
> support requests by this.

No links will ever be broken unless we ever decide to officially drop one 
compiler for good. And again, the current solution does not offer a sensible 
transition path for that, either. MinGW3 users just stopped seeing updates.

And it's going to be the same for any compiler / flavor you may wish to add in 
the future, too. Either you support it for all eternity, or you're going to 
cause _some_ transition troubles sooner or later. I believe my suggestion 
makes those transition troubles less severe. So it may even lower the barriers 
towards experimenting with yet another compiler / flavor.

BTW, here's an obvious alternative variant to my suggestion, but I don't think 
it's the better one: Decouple the schedules, but do not change anything in the 
installer. E.g. go ahead with releasing 4.5.x MinGW-flavor, and add MSVC-flavor 
some time later. But this would lead to MSVC-users wondering, why they don't 
get to see the new release. The idea of splitting up the installer is 
precisely about communicating that release schedules for different compilers 
are decoupled.

> In the opposite there is the single installer approach with a minimal
> gui approach, see
> http://www.winkde.org/pub/kde/ports/win32/setup/stable/ - but in both
> case some people are not satisfied.

At this point my primary concern is not about making the installer simpler, 
although yes, at least that will be a small side-effect. It's about making the 
process of creating releases managable.

I mean, hey, it just isn't working out all that great, is it? So let's face 
the _fact_ that ressources are limited, and find a sensible way to cope with 
that. If the situation changes in a few years, if it all becomes automated, 
and hordes of volunteers are waiting in line, hoping to be the one to be 
allowed to push the button... Going back towards a unified installer, then, 
should not be a problem.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20101106/24c12543/attachment-0001.sig