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 8082713877A for ; Sat, 9 Aug 2014 17:42:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E574E0951; Sat, 9 Aug 2014 17:42:20 +0000 (UTC) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 56585E093E for ; Sat, 9 Aug 2014 17:42:19 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id a108so7193881qge.2 for ; Sat, 09 Aug 2014 10:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KtozQ8IIGM+kuyTq5y0WTFDAU4MAfOGv2ieSFlAhrsw=; b=n6x7sL/i48xDk+jKxmUt99GYWs3NLr1WV/72kK9+PCXIXqjFzZUzKro8dafL4I1Khf /zf1XYFqVTrYCMclQhyWa0IZJoMBc4TiNZWtQ2kVqzHb0NSv4grwJBBc1LCfIPG7x52w qa4ZFS0IeTScqcfk6AcFC2XSBdWE0iC1E9jlKLaH6jGUFscB2DaO1C9J2va64IWY1PBc zQPQNL9Xjox3EJIIo3I7sd4Krt+IRAObm0rvDqvmYse/Rq6LNwHxpr0ZIwResOSrlYWP HzAAA8+LQfVQOG1LQ1CO6TCV5ndwS31tJVcX4dVAo7b4eTbmMPj5sGoxltnCUqacx0Y/ 75sA== 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 X-Received: by 10.140.43.70 with SMTP id d64mr28648324qga.74.1407606138446; Sat, 09 Aug 2014 10:42:18 -0700 (PDT) Received: by 10.140.44.34 with HTTP; Sat, 9 Aug 2014 10:42:18 -0700 (PDT) In-Reply-To: <53e649e6.c8a1980a.2941.4762@mx.google.com> References: <53e649e6.c8a1980a.2941.4762@mx.google.com> Date: Sun, 10 Aug 2014 05:42:18 +1200 Message-ID: Subject: Re: [gentoo-dev] A constructive reommendation on stablity improvemt From: Kent Fredric To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=001a113a9e6cdda8ec050035d71e X-Archives-Salt: 13f1e62e-c597-4ec7-be6b-d67da69461c8 X-Archives-Hash: 3296b580d2c1a40188336bfb69e91178 --001a113a9e6cdda8ec050035d71e Content-Type: text/plain; charset=UTF-8 On 10 August 2014 04:18, Igor wrote: > 5. Wait for server-side implementations to appear. They will appear once > emerge can report. And once it's clear for the rest that there is > seriously > going to be a change soon. > It really needs to be designed from the server side, not the client side. And defaulting on is a bad default. The reason the server part has to come first is the server side serves as reference implementation of how the communication protocol is to work, and how reports are to be aggregated. The best part here, is the server can also be designed without needing to modify the portage source. The server can be created, and a dummy client can be created that speaks its language and submits "sample" reports of some kind. Once the server is doing what it needs to do as a basic feature set in recording and storing reported data, the dummy client can be enhanced to be an out-of-band too that reports information by scraping portage logs. And using that process means we can iteratively refine what needs to happen without hamstringing us by being tightly coupled with the portage release process. Once we have a reference and useful enough server and protocol specification, *THEN* we can talk about integrating it with portage and other clients. And its much more likely we'll have competing clients in circulation that speak the protocol than it is that we'll have competing servers all working with a unified client. ^ This much is apparent from observing the CPAN model, we have a variety of client libraries because different ones prove more practical for end users for certain workflows, but we only have one server that is the recipient for the reports. There is of course value in being *ABLE* to provide competing servers, but competing servers are way outside the problem domain that proves relevant to Gentoo. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL --001a113a9e6cdda8ec050035d71e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 10 August 2014 04:18, Igor <lanthruster@gmail.com> wr= ote:
5. Wait for server= -side implementations to appear. They will appear once
=C2=A0 =C2=A0emerge can report. And once it's clear for the rest that t= here is seriously
=C2=A0 =C2=A0going to be a change soon.

<= div class=3D"gmail_extra">It really needs to be designed from the server si= de, not the client side.

And defaul= ting on is a bad default.

The reason the server part has to come= first is the server side serves as reference implementation of how the com= munication protocol is to work, and how reports are to be aggregated.

The best part here, is the server can = also be designed without needing to modify the portage source.

The s= erver can be created, and a dummy client can be created that speaks its lan= guage and submits "sample" reports of some kind.

Once the server is doing what it needs= to do as a basic feature set in recording and storing reported data, the d= ummy client can be enhanced to be an out-of-band too that reports informati= on by scraping portage logs.

And using that process means we can it= eratively refine what needs to happen without hamstringing us by being tigh= tly coupled with the portage release process.

Once we have a reference and useful enough server and protocol specificatio= n, *THEN* we can talk about integrating it with portage and other clients.<= br>
And its much more likely we'll = have competing clients in circulation that speak the protocol than it is th= at we'll have competing servers all working with a unified client.

^ This much is apparent from observing= the CPAN model, we have a variety of client libraries because different on= es prove more practical for end users for certain workflows, but we only ha= ve one server that is the recipient for the reports.

There is of course value in being *ABL= E* to provide competing servers, but competing servers are way outside the = problem domain that proves relevant to Gentoo.


--
--001a113a9e6cdda8ec050035d71e--