Rant: So you want help?
thomas.friedrichsmeier at ruhr-uni-bochum.de
Sat Nov 6 09:26:32 CET 2010
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.
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
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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
More information about the Kde-windows