From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 378AA1381F3 for ; Fri, 23 Aug 2013 15:54:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 02CE8E0C9B; Fri, 23 Aug 2013 15:54:45 +0000 (UTC) Received: from juliette.telenet-ops.be (juliette.telenet-ops.be [195.130.137.74]) by pigeon.gentoo.org (Postfix) with ESMTP id 8A37BE0C8F for ; Fri, 23 Aug 2013 15:54:43 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by juliette.telenet-ops.be with bizsmtp id GFuY1m00M2khLEN06FuYJR; Fri, 23 Aug 2013 17:54:32 +0200 Date: Fri, 23 Aug 2013 17:54:26 +0200 From: Tom Wijsman To: gentoo-dev@lists.gentoo.org Cc: slong@rathaus.eclipse.co.uk Subject: Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8 Message-ID: <20130823175426.36d89cb7@TOMWIJ-GENTOO> In-Reply-To: <20130823132702.GA2106@rathaus.eclipse.co.uk> References: <20130808202627.4b474471@TOMWIJ-GENTOO> <20130809020303.GA11215@linux1> <1376033807.30224.21.camel@kanae> <5204B6A9.1080309@gentoo.org> <5204E235.7010702@gentoo.org> <20130809151307.77ee9039@TOMWIJ-GENTOO> <20130810193458.GB1500@rathaus.eclipse.co.uk> <20130810214904.360a3a4c@TOMWIJ-GENTOO> <20130823132702.GA2106@rathaus.eclipse.co.uk> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.20; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/3SQJrT8fjLByY0OTpgIv8Vg"; protocol="application/pgp-signature" X-Archives-Salt: fd011844-0e44-491c-a906-5f7e12e60b7f X-Archives-Hash: 71e736355a7e5d385335b82eb3a48118 --Sig_/3SQJrT8fjLByY0OTpgIv8Vg Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 23 Aug 2013 14:27:02 +0100 "Steven J. Long" wrote: > On Sat, Aug 10, 2013: > Tom Wijsman wrote: > > "Steven J. Long" wrote: > >=20 > > > The core system has to be a usable basis to build "everything" > > > from. > >=20 > > I do agree with this except for "shaky"; it is a nice goal to > > pursue... > >=20 > > That still does not make us able to do it or make it a realistic > > goal. >=20 > But it's exactly what the standard Gentoo install supplies, or used > to. So it's very realistic, since it's the basis we've been using for > a decade. You start from something small, which does the described thing; but once you grow to something bigger, you are suddenly no longer able to satisfy that description. In order to continue to grow bigger, you need to cut corners and take decisions; in other words, you can no longer hold on to the prototype that was made but start to need to face the realism that is out there. Just because you can start with something, doesn't mean it is scalable; supporting more comes at its own cost, which may not give enough ROI. > And you are able to do it. At the cost of other things; so, in the whole picture, one can think of it as an unrealistic goal unless someone does want to do all the work without leaving other users that use the software product in the dark. > Losing that capability is nothing more or less than a regression for > a meta-distribution. It is as much a loss as it is a gain; a software product that doesn't deal with bugs because it has to be busy with supporting everything that is out there, is going to leave other regressions behind as well. > > > Design choices have consequences in terms of where manpower can > > > go, as well as in terms of end-user capability and flexibility, > > > especially when one of the "options" has far-reaching implications > > > for the rest of the stack, such that it is a question of "my way > > > or the high way," which seems counter to the idea of choice i > > > hear so much about. > >=20 > > "My way or the high way" is giving good service to just a set of > > users, because you can't listen and support everyone with limited > > resources; as a result it causes alternatives to be created, > > effectively giving choice. >=20 > This is a total non-sequitur, given that we already have choice. You have a choice, but don't have support for it; it is still their choice whether to choose to support you, and when they do, they are giving less support in other places as a result of a cost in time. > Taking it away does not create choice: it merely restricts everyone > until a "hate" fork happens, or some other alternative is provided, > to restore the previous state of affairs. Well, such happenings would introduce a supported choice. > Though to be honest, your argument is more akin to a conceptual > discussion as to "whether an argument could be made" rather than > "what is the best way forward in the long-term for the diverse > user-base." Not very practical, imo. As long as nobody wants to do the work, it remains conceptual; the best way forward is to work with what we are given, until someone gives us what we want or we really want to do the work we want ourselves. > "Giving service to a set of users" is not at all the same as "my way > or the high way." The latter is what happens when you get non-modular > software that tries to do too much, under the banner of "One True > Way" to disguise the awful coupling, however it's dressed up. There are not a lot of products that can give service to everyone; so, people use what they believe is the "One True Way" for them. > The former is what happens when you install say an httpd to serve an > intranet. It doesn't dictate what other pieces of software you can > use for orthogonal purposes (or suddenly expand its feature-base to > include everything else so it isn't orthogonal any more.) When you buy a small row house without a garage or a ramp; you will not be able to park your car in your just bought house. If you try to do it anyway, you will break it. > > This is a natural thing to happen, as everything supporting > > everything does not sound possible at all; it is therefore > > unrealistic. >=20 > What's unrealistic is expecting us to swallow regressions as progress. The opposite is also unrealistic; so, they had to make a design choice. --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/3SQJrT8fjLByY0OTpgIv8Vg Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) iQEcBAEBAgAGBQJSF4W2AAoJEJWyH81tNOV9guMH/RQvdMrecoRuqIKrnxWGqNEM RYuZH8EZCuuhs7TwuFIgUt1F0pMIHXIMmDuo6kJBnIFNE8WpRXuQkvyN5snLePXt 1eB4st2fkZcDwvQ8gsDCPLUH1ENO2wf9/pfLAIMeKkS+wuTEMR8Z7uXi3Ezpq/BC C8cimjEcNy/8N0Cwne674KMwxLmUj9xvjS69Nco7YD3F4LR5jRd+L4avAneBMtq9 o3A4IUxKtRMtv1VPbPxzFu/jSYId3K7Rje3yKn1gIdKOtTbLqiyD2vA1HUZElW7T M8I5QWiK/9v6r5YXAzWsUtxi+EX/D+vF+vu24BLoEih0hD6mGLSsSCgWS/vatIo= =MNUy -----END PGP SIGNATURE----- --Sig_/3SQJrT8fjLByY0OTpgIv8Vg--