Re: [gentoo-dev] A constructive reommendation on stablity improvemt

[Kent Fredric]

On 10 August 2014 04:18, Igor <lanthruster@×××××.com> 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