| 1 |
On August 9, 2014 10:56:49 AM EDT, Igor <lanthruster@×××××.com> wrote: |
| 2 |
[snip] |
| 3 |
>Just the main blockers are: |
| 4 |
> |
| 5 |
>- Somebody has to implement this technology |
| 6 |
>- That requires time and effort |
| 7 |
>- People have to be convinced of its value |
| 8 |
>- Integration must happen at some level somehow somewhere in the |
| 9 |
>portage toolchain(s) |
| 10 |
>- People must opt in to this technology in order for the reports to |
| 11 |
>happen |
| 12 |
>- And only then can this start to deliver meaningful results. |
| 13 |
> |
| 14 |
> |
| 15 |
> |
| 16 |
>IMHO seriously, it could be done if ONLY portage dev team would |
| 17 |
>implement |
| 18 |
>an interface CAPABLE for HTTP reporting. Once the interface is there |
| 19 |
>but turned off |
| 20 |
>by default - server side statistics are feasible. Personally I don't |
| 21 |
>see any future of |
| 22 |
>this system unless it's coded in portage. Today - portage support |
| 23 |
>without server side |
| 24 |
>- tomorrow - server side. |
| 25 |
|
| 26 |
Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for "Portage QOS" or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying "we should have (some feature)" doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. |
| 27 |
|
| 28 |
Chris Reffett |
| 29 |
-- |
| 30 |
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
Archives