From kde-windows Sat Nov 06 08:26:32 2010 From: "Thomas Friedrichsmeier" Date: Sat, 06 Nov 2010 08:26:32 +0000 To: kde-windows Subject: Re: Rant: So you want help? Message-Id: <201011060926.35787.thomas.friedrichsmeier () ruhr-uni-bochum ! de> X-MARC-Message: https://marc.info/?l=kde-windows&m=128903203828507 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0058416506==" --===============0058416506== Content-Type: multipart/signed; boundary="nextPart1876389.ulW8SR1xjm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1876389.ulW8SR1xjm Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 "tradition= al"=20 way sooner or later. But for all I've heard, having timely releases will be= an=20 issue again, and again, and again in the future. *One* reason for this is that the barriers to a release seem tremendously=20 high. Supporting two or three compilers *at once* looks like one of the=20 central barriers to releasing anything at all. For instance, I'm always low= on=20 hard disk space, and I don't even have a 64bit windows. So, if *I* am to=20 participate actively in releasing, I need to find a way to make it managabl= e.=20 If you're saying the release process is hard to break up, *and* you need to= do=20 it for three compilers, then *I* am not the volunteer you're looking for.=20 Sorry. =20 The key idea, here, is that different compilers can be handled by (potentia= lly)=20 independent teams (read: those you really care about having an end-user=20 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 32bi= t=20 incarnation. So we want to support compiler diversity, but there's no reason why we=20 shouldn't encourage a compiler default for end users. MinGW 32bit looks lik= e=20 the obvious choice to me, because =2D 32bit will work for all users =2D GCC is the predominant compiler in the KDE world, so creating a MinGW b= ased=20 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=20 websites that do care, will finally get a decent possibility to enforce thi= s.=20 E.g. because they provide add-on binaries that only work with *one* of the= =20 compilers, or because their application is known to malfunction with anothe= r=20 of the compilers, etc. MSVC-users will be told by the kdewin-installer-latest.exe that they need t= o=20 install from scratch. Tough luck. But then, it's not like updating an exist= ing=20 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, y= et?=20 Who told users of MinGW3 installations why they were not finding any update= s in=20 the 4.3.x and above directories on any mirror (and this transition, too, co= uld=20 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=20 compiler for good. And again, the current solution does not offer a sensibl= e=20 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=20 the future, too. Either you support it for all eternity, or you're going to= =20 cause _some_ transition troubles sooner or later. I believe my suggestion=20 makes those transition troubles less severe. So it may even lower the barri= ers=20 towards experimenting with yet another compiler / flavor. BTW, here's an obvious alternative variant to my suggestion, but I don't th= ink=20 it's the better one: Decouple the schedules, but do not change anything in = the=20 installer. E.g. go ahead with releasing 4.5.x MinGW-flavor, and add MSVC-fl= avor=20 some time later. But this would lead to MSVC-users wondering, why they don'= t=20 get to see the new release. The idea of splitting up the installer is=20 precisely about communicating that release schedules for different compiler= s=20 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,= =20 although yes, at least that will be a small side-effect. It's about making = the=20 process of creating releases managable. I mean, hey, it just isn't working out all that great, is it? So let's face= =20 the _fact_ that ressources are limited, and find a sensible way to cope wit= h=20 that. If the situation changes in a few years, if it all becomes automated,= =20 and hordes of volunteers are waiting in line, hoping to be the one to be=20 allowed to push the button... Going back towards a unified installer, then,= =20 should not be a problem. Regards Thomas --nextPart1876389.ulW8SR1xjm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkzVETgACgkQEKRv+5DVNhjJ6ACgoPs8Sti2jSTukfVH3eoMHFsw AJgAn0QD8ajhHj1l812Id7evtW3PAOO8 =wC1T -----END PGP SIGNATURE----- --nextPart1876389.ulW8SR1xjm-- --===============0058416506== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows --===============0058416506==--